Concurrency and shared library issues

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.