The terminology "wait-free atomic registers" seems to be unique to the distributed systems literature, which makes this question difficult to answer directly.

Within a single core of a modern superscalar machine, an architectural register (like eax on x86) gets renamed after decode.  Typically this register renaming results in a new name at each assignment, so the renamed registers are written once at creation and then immutable, making atomicity a simple scheduling issue.  During execution, a "renamed register" often acts less a storage circuit and more as a tag to identify the correct data forwarding path between execution units.  Some registers such as machine control registers are not renamed, but access is controlled by a dedicated arbitration circuit.

In a multi-core machine, normally registers are only accessible from a single core.  The storage shared between cores is the memory hierarchy, and the cache coherence protocol enforces the machine's memory consistency model.  Some researchers in transactional memory have been pushing atomicity down to the memory hardware, which seems similar to what you're asking about.

Discovering the correct terminology is often the most difficult part of a literature search!

http://www.agner.org/optimize/microarchitecture.pdf

http://www.christianjacobi.de/publications/jsg12_tx.pdf

Dear Orion Sky Lawlor, thank you for the reply. I agree with you that "discovering the correct terminology is often the most difficult part of a literature search", and I am sorry that my question was not precise. I will try to explain it better and edit the question to make it more clear. Basically, what I am interested in is the implementation in single-core/multi-core machines of what in distributed systems is called an Atomic Register, i.e. a shared memory area that can be read by one or more reader threads and written by one or more writer threads in a way such that the resulting execution is serializable and each read operation returns the last value written. This can obviously be realized using a lock/semaphore, but what I am interested in is a wait-free implementation (e.g. using compare-and-swap, fetch-and-add and/or similar atomic primitives available in modern processors).

The key question here is what memory consistency model your hardware is using.  If an application can tolerate relaxed consistency, ordinary software loads and stores will perform well and match up with each other between threads in some order, but due to caching write visibility may be delayed by different amounts on different threads.

Sequential consistency (serializable execution order) is a stringent requirement, but typically can be requested explicitly using a memory fence instruction.  This behavior is now standardized in C++11 in the header , so std::atomic_store_explicit(&arr[i], newvalue, std::memory_order_seq_cst) will emit the appropriate write and fence for your hardware.  On current x86 machines, this uses the "mfence" instruction, which has a high performance cost--over 11 nanoseconds!

See [Adve and Gharachorloo, 1995] for a readable justification of hardware's now ubiquitious use of relaxed memory consistency.

http://en.cppreference.com/w/cpp/atomic/atomic_store

http://en.cppreference.com/w/cpp/atomic/memory_order

Dear Orion,

I was aware of the importance of the memory consistency model, but I must admit that I'm not an expert in this field, so thank you very much for the useful links (especially the paper)! Nevertheless, in my opinion (but please correct me if I'm wrong and feel free to add further considerations), even sequential consistency does not seem to be sufficient for realizing an atomic register. The problem is that in the atomic register, in addition to avoid conflicting r-w operations, we need to enforce a logical ordering that goes beyond what sequential consistency can guarantee, i.e. if a read operation R1 completes and returns (to the application) a value with timestamp T1, no other read operation R2 that completes after R1 can return a value with timestamp T2 < T1. To guarantee such a property, I believe it is necessary to devise a proper algorithm (at the software level), that is what I meant when I asked for the state-of-the-art implementation of an atomic register.

Best regards,

FC