Concurrency and shared library issues

There's an old proverb: "Be careful what you ask for--you might get it." This definitely applies to preemptive multitasking. It solves many problems, but like any panacea, it introduces new ones. The big problem for preemptive scheduling is concurrency and synchronization. If multiple threads are changing or reading data structures at the same time, the chance that the data structures will be consistent is about nil.

One approach is to require that every object in the system be safe for use by multiple concurrent threads. This works, but has a big performance impact and very little benefit. For example, consider an object A, which is built out of other objects B, C, D, and E, which are all safe for use by multiple threads. This does not mean that A is therefore safe for use by multiple threads. Although B, C, D, and E all separately preserve their individual invariants, that doesn't mean that A's invariants are preserved. In fact, in making A multithread safe, it is often the case that the components' being multithread safe is of little or no use, as it is A in its entirety which must be synchronized.

Therefore, synchronize high-level constructs only; avoid synchronization at a low level because it has storage and time penalties. There are some exceptions; Taligent's MReferenceCounted is multithread safe because it enables programming that is also multithread safe without any additional overhead (see "Surrogate objects" on page 121). However, the Collection classes are not multithread safe because you usually use them to construct other objects, rather than access them directly from multiple threads.

[Contents] [Previous] [Next]
Click the icon to mail questions or corrections about this material to Taligent personnel.
Copyright©1995 Taligent,Inc. All rights reserved.

Generated with WebMaker