pre-LilleHammer mailing deadline

[Doug Lea]

> 
> There is no mention of atomic operations other than as the potential
> semantics of access to volatile objects.  If I'm not very much mistaken,
> read-modify-write operations are essential to most lock-free algorithms.
> Is there consensus that these belong in the library?  

I think so. At least I haven't heard anyone suggest otherwise.

> In any case, is
> there not a question, similar to that for atomicity of volatile access,
> of whether they should be optional, given the variation in native atomic
> operations between architectures?
> 

I think we have a better story for this. The main
issue with "volatile" is that it can modify any type.
But the library classes like atomic_int in original proposal
are not tied to other types. So for example, a platform
without native CAS or LL/SC or even read atomicity of ints
can provide a version in which each atomic_int houses a lock (maybe just
an interrupt-disable lock on an embedded uniprocessor).

We have still yet to list out the weaker variants of
atomic_int.get/set we've discussed. But I don't think this
lack reflects any intersting issues; just not getting around
to it.

-Doug