[cpp-threads] RE: C++ Connections proposal

[Alexander Terekhov]

Err..

On 4/26/05, Alexander Terekhov <alexander.terekhov at gmail.com> wrote:
> On 4/25/05, Boehm, Hans <hans.boehm at hp.com> wrote:
> [...]
> > inlining the pthread primitives.  You are just moving
> > things down a level; the "opaque calls" are now the CAS
> > instructions or the like.
> 
> Pthreads aside for a moment, think of refcounting under basic
> thread safety -- stuff along the lines of std::string COWs and
> tr1::shared_ptr/weak_ptr. You really don't want "opaque" (full-
> stop compiler fence) atomics for increments (they can be
> totally naked) or decrements (they need relaxed value
> dependent acquire-release protocol [msync::cchlb -> msync::
> cchsb] in the case of immutable managed objects instead of

I meant msync::cchsb (hoist store barrier -- part of classic {cc}
acq) -> msync::slb (sink load barrier -- part of classic release).

Pirate (sink and hoist) talk aside for a moment, in Sparc RMO
terms, it needs

  membar load-store   
  <atomic load-modify-store> // decrement
  membar store-store 

to "preserve" the order of preceding loads and subsequent stores 
with respect to "dumb" (no value dependent msync and control 
condition hint) refcount decrement. Or, given that Sparc orders 
CAS as both load and store,

  membar load-load // same slb effect as load-store -> CAS on Sparc
  <compound atomic load-modify-store> // decrement
  membar load-store // same hsb effect as CAS on Sparc -> store-store

With value dependent msync and control condition hint we
need leading fence (e.g. in CAS.slb; or just use state machine
and hoist it out of loop) when new value is nonzero, and, in the 
case zero case, we can omit trailing fence (in CAS.cchsb so to 
speak) completely because msync::cchsb is implied on Sparc 
due to conditional branching, IIRC. Similar stuff on Power, Itanic, 
and Alpha. 

> "full" [but still value dependent] acquire-release protocol in the
> case of mutable ones).

"Full" in the sense of value dependent rel -> ccacq protocol 
("value is likely to be one" bias on tr1::shared_ptr's weak count
and omission of zero store for both weak count and std::string- 
like COW's refcount aside for a moment). Peter knows it better, 
just ask him. ;-)

> 
> >
> > I'm not sure how many systems actually have the option of
> > inlining pthread primitives.
> 
> Pthreads-win32 can do it, IIRC. ;-)

regards,
alexander.