intvariable (declared volatile so that the compiler doesn't put it in a register), you might assume that if the only values written to it are in some set, another thread reading that variable sees one of the values in that same set. That isn't the case, because vagaries in instruction processing and memory subsystems make it possible for the variable to momentarily assume values outside the set when read in an unsynchronized way. Also, writes and reads from different processors on a multiprocessor can appear out of sequence.
In general, it isn't possible to write portable C++ code where multiple threads simultaneously read and write a memory location. Of course, multiple threads can safely read a storage location without synchronization as long as none are trying to write it at the same time. Taligent engineers must consult with an architect before doing so.
|Complex data structures that do not need locking|
|The idea of accessing data structures without locks is actually an active topic of research these days, and is sometimes called lock-free synchronization. Given one or more primitive atomic operations, it is possible to build more complex data structures that do not need locking.||Such primitives include the 68030 Compare-and-Swap instruction and the PowerPC Load-Reserve/Store-Conditional instructions. The Taligent Application Environment runtime uses such techniques to implement the heap allocator. MReferenceCounted also uses this technique on some platforms.||In the future, Taligent might decide to support one or more of these primitives across all Taligent Application Environment systems; then you can write portable code that uses them (the storage allocator has nonportable portions anyway). For now, do not use these constructs without your architect's approval.|