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.