Subj : Re: Memory visibility and MS Interlocked instructions To : comp.programming.threads From : Alexander Terekhov Date : Fri Aug 26 2005 04:41 pm Joe Seigh wrote: ... 1.1 Atomics library approach We have been discussing a library design in which primitives atomically read and/or update a memory location, and may optionally provide some memory ordering guarantees. Nearly all lock-free algorithms require both atomic, i.e. indivisible, operations on certain pieces of data, as well as a mechanism for specifying ordering constraints. Allowing them to be combined in a single operation (as opposed to providing separate atomic operations and “memory barriers”) makes it possible to cleanly and precisely express the programmer’s intent, avoids some unnecessary constraints on particularly compiler reordering, and makes it easy to take advantage of hardware primitives that often combine them. [...] On the vast majority of existing X86 processors, the “load” and “load with acquire ordering semantics” primitives could use the same hardware implementation, and would merely impose different compiler constraints. Other processor architectures are split as to whether they require separate implementations. The same applies to “store” and “store with release semantics”. We expect that in the final version of the library, operations such as load and store will be parameterized in some form with an ordering constraint Why don't you simply spend your weekend studying the archives, Joe. jupiter.robustserver.com/pipermail/cpp-threads_decadentplace.org.uk regards, alexander. .