On Tue, 14 Aug 2007, Chris Snook wrote:

Because atomic operations are generally used for synchronization, which
requires volatile behavior.  Most such codepaths currently use an inefficient
barrier().  Some forget to and we get bugs, because people assume that
atomic_read() actually reads something, and atomic_write() actually writes
something.  Worse, these are architecture-specific, even compiler
version-specific bugs that are often difficult to track down.

Looks like we need to have lock and unlock semantics?

atomic_read()

which has no barrier or volatile implications.

atomic_read_for_lock

	Acquire semantics?


atomic_read_for_unlock

	Release semantics?