[boost] [thread] Some thoughts about "atomic"

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-12-01 05:33:26

After having tried to learn about atomic from reading through several 
articles, processor specs and mailing lists, I am more confused than before.

I would be glad if we could (re)start a discussion about the topic. 
Perhaps I am not the only one to benefit from this.

Following are some things I learned, but this might be wrong, and I 
would appreciate clarification. Also some questions:

1)     atomicity (in this specialized context) is about optimizing the 
pattern: enter_critical_section; do_something; leave_critical_section; 
by making use of processor/platform specific means. In particular in 
presence of multiple processors. I.e. an atomic lib is primarily about 
performance.

2)     atomicity better would be addressed by the compiler, given a 
suitable memory model, than as a library.

3)     Despite 2) it would be possible to write a library, but it will 
be hard to get processor independent semantics. E.g. there is one 
concept of read/write/full memory barriers or another of acquire/release 
semantics for SMP.

4)     Does there exist a canonical set of atomic primitives, from which 
others can be built? E.g. given atomic_test_and_set, atomic_load and 
atomic_store is it possible to emulate atomic_compare_and_swap? (without 
use of system mutices of course.)

5)     Is it worth the effort to create a library with processor 
independent semantics, at the price of not being optimal? E.g. by doing 
away with the various kinds of barriers, instead simply requiring 
atomicity and full memory barrier semantics for the operation? Which 
operations, besides load and store would be essential?

Sorry if this is not the perfect list to discuss the topic, but I think 
boost could possibly benefit from such a library, as previous 
discussions let me believe.

Regards,
Roland