[cpp-threads] Update

[Peter Dimov]

Boehm, Hans wrote:

> I made another pass over the atomic operations proposals that were
> previously discussed here, and turned them into N2047
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html).

I like the new direction the atomic interface is taking. Now we just need to 
drop the "high-level" part entirely and work out the remaining issues in the 
low-level part. :-)

* The main problem I see in the low-level interface is that it has too many 
feature tests that basically support dead or dying platforms. Sure, it 
grants us the ability to say that we "support" nearly every platform, but 
what are the practical benefits of doing so? From a practical point of view, 
a platform either has atomics or it doesn't. One difference that matters in 
practice is whether it has double-width atomics, but the current interface 
doesn't provide access to them.

* atomic_exchange (or _swap, if you prefer) is missing.

* I prefer _none, _acq(uire), _rel(ease) and _full for suffixes, but that's 
not particularly important. Slightly more important is whether the unordered 
load/store need a suffix (and whether they need _full variants). I think 
that they do.

* This is how I think atomic_cas needs to be specified:

bool atomic_cas( T * addr, T * oldv, T newv );

Effects: if *addr contains the value *oldv, atomically updates *addr to 
contain newv and returns true, otherwise stores *addr in *oldv and returns 
false. When T is not a built-in type, performs a bitwise comparison.

This formulation supercedes both strong CAS and weak CAS, as it's allowed to 
fail. A strong CAS is easily built on top of it by using a retry loop.

Example use:

  {
      long st = atomic_load_none( &state_ );

      for( ;; )
      {
          if( st & state_w_mask ) break;
          if( atomic_compare_exchange_acq( &state_, &st, st + 1 ) ) return; 
// got read lock
      }
  }

* I'd really like to see atomic_decrement_<order1,nonzero>_<order2,zero>, or 
at least atomic_decrement_release_acquire. This primitive is essential for 
correct reference counting. The closest the current proposal has is 
atomic_fetch_add_ordered. It may be argued that it's close enough for all 
contemporary platforms.

As an aside, does anyone know "the suffix" of the Solaris atomics, in other 
words, their memory synchronization properties?

http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/sys/atomic.h
http://cvs.opensolaris.org/source/xref/on/usr/src/common/atomic/

http://docs.sun.com/app/docs/doc/816-5168/6mbb3hr32?a=view