[boost] Re: copy_on_write

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2005-06-02 04:43:33

Maksym Motornyy wrote:
> 
> Wow! Really cognitive discussion :) But wait a moment, can someone tell
> me is COW worth to be a part of Boost or not?

Interface considerations to make COW'd stuff like containers and strings 
somewhat less surprising (to uninformed) aside for a moment, with respect 
to threading it all boils down to having efficient COW_refcount<size_t, 
thread_safety::basic>, so to speak. 

< Forward Inline >

Subject: Re: Quetions about Mac OS X synchronization primitives

On Apr 10, 2005 5:38 PM, Alexander Terekhov wrote:
> "Peter Dimov" schrieb am 09.04.05 12:15:25:
> >
> > Philip Koch wrote:
> > > On Apr 8, 2005, at 3:31 AM, Peter Dimov wrote:
> > >
> > >> It would be nice if we could do that and achieve a near-optimal
> > >> implementation. At the moment we need
> > >>
> > >> - an increment without a barrier
> > >
> > > OSAtomicIncreement32
> > >
> > >> - an increment when the old value is nonzero without a barrier
> > >> - a decrement that is a release when the new value is nonzero and
> > >> an acquire when the new value is zero
> > >
> > > Send me a more precise description of what you need, and we'll
> > > consider putting them in a future release.  If as you say they will
> > > be needed by c++, we'll probably need to.

Consider putting a bunch of additional decrements tailored for
immutable shared_ptr<>-managed client objects and mad
std::string cows (I mean COW with "unsharing" on nonconst
operator[] and alike).

> >
> > SInt32 OSAtomicIncrementIfNonzero32( SInt32 * address );
> >
> > Atomically increments *address if its old value is nonzero.
> > Returns the old value of *address.
> >
> > SInt32 OSAtomicDecrementRelAcq32( SInt32 * address );
> >
> > Atomically decrements *address.
> >
> > If the new value of *address is nonzero, has release memory synchronization
> > semantics.
> >
> > Otherwise (when the new value of *address is zero), has acquire memory
> > synchronization semantics.
> >
> > Returns the old value of *address.
> >
> > (or they could also return the new value; it doesn't matter.)
>
> SInt32 OSAtomicDecrementWeakRelAcq32()
>
> As above, but optimized for "old value == 1" case and allowed to drop zero
> store.

SInt32 OSAtomicDecrementSlbHsb32( SInt32 * address );

Same as OSAtomicDecrementRelAcq32() above, but it doesn't put a barrier
on sinking stores (puts a barrier on sinking loads only) when the new
value of *address is nonzero, and, in the case of zero new value, it
doesn't put a barrier on hoisting loads (puts a barrier on hoisting
stores only). You can probably drop trailing isync for it (IIRC Power
doesn't hoist stores above control conditions).

As for mad std::string cows... hmm, I need more time. Quick shot is that
it needs something along the lines of OSAtomicDecrementWeakUnbiasedSlbHsb32()
and OSAtomicDecrementIfGreaterThanOneSlbHsb32() with checking and no
msync for zero ("unsharable" indicator").

>
> Plus  OSAtomicFetch32() and OSAtomicStore32() (naked ones) in order to
> remove dependency on C/C++ volatiles.

And OSNonatomicStore32() to properly label exclusive noncompeting store
of "unsharable" (zero) indication for mad std::string cows.

BTW, I don't know exactly what SInt32 means, but for refcounting, an
opaque (so that it can be a structure or whatever providing proper
isolation -- alignment and padding if needed) SAtomicUnsignedCount32
with corresponding INIT macro would do better.

Almost as good as refcount<size_t, thread_safety::basic>... ;-)

regards,
alexander.