Power and Perils of Sharing

Design Note #7:

Sharing of information and resources is one of the most important things our applications do. There are several types of sharing that are quite common in applications being built today:

Web servers share information with clients and often allow them to modify or extract parts of the shared information, e.g., edit a Wiki page, place an order, download a file.
Code is shared by many parts of a single application and often across many applications, e.g., compiler libraries and resusable code we create for a project.
Resources like streams, queues, files, and locks are shared by different packages and multiple threads, perhaps in a single package.
Critical business data is shared between departments and with clients, suppliers, and distributers.

But the benefits of sharing come with costs and problems. One client may make changes that adversely affect another. Two clients may attempt to concurrently acquire a resouce causing one to block or perhaps corrupting the state of the resource. Proprietary or secret information may be inadvertently disclosed through sharing of resources.

Sharing is a fundamental part of our enterprise systems. Banking, Police, Governmental, Medical, and Corporate operations could not carry out their functions without sharing information and resources. This website is an exampe.

However, ensuring the safety, correctness, security, and timeliness of sharing information and resources is difficult - often exraordinarily difficult. We have smart young men and women here at Syracuse University earning doctorate degrees through research on these problems.

All Graphical User Interfaces, communication systems, and operating systems depend on sharing messages, data, and information between threads.

This type of sharing has its problems too - corruption of data when sharing is not properly serialized with locks, deadlocks, thread starvation, and priority inversion, just to name a few.

We discuss all of these in both this course and in CSE681 - Software Modeling and Analysis. We will see that serialization is a solved problem in principle, using locks, provided that we keep our threading models simple. All the other problems need to be carefully addressed as design issues and monitored with rigorous testing.

The best way to manage sharing is to do the least amount possible, but no less. Identify all the areas of sharing, and build your designs and test plans around them. Finally, build logging facilities to continuously monitor the health of shared information and resources.

Conclusions for: Power and Perils of Sharing

Your applications will share user information, external information from stored data, resources like streams, files, queues, and memory.

Do the least amount of sharing possible and still provide the application's functionality.
When you allocate shared resources like files, streams, and database locks, release them as soon as you have finished. Your design should strive to make the duration of use as small as possible.
Return shared resources, when you've finished, in the same state you found them, unless every single user agrees that the modifications are intended and expected.
Keep sharing between theads localized and simple as possible. Sharing through carefully constructed thread-safe containers like Blocking Queues makes threaded designs managable.

CSE687 - Object Oriented Design

Design Note #7
Power and Perils of Sharing

Design Note #7:

Conclusions for: Power and Perils of Sharing

CSE687 - Object Oriented Design

Design Note #7Power and Perils of Sharing

Design Note #7:

Conclusions for: Power and Perils of Sharing

Design Note #7
Power and Perils of Sharing