Re: shared_count

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-02-12 14:19:39

--- In boost_at_y..., "Yitzhak Sapir" <ysapir_at_y...> wrote:
> It is hard for me to follow to what point you are in the discussion 
now.
> However, I wish there were some portable library that implemented a 
wide
> variety of atomic operations.  Test and Set could be implemented in 
the
> context of some hypothetical atomic_bitset<N>, or 
atomic_bitvector<N>,
> shared count as atomic_long, etc.  atomic_long could also provide 
for
> atomic exchanges (via swap specializations).  In all these 
operations,
> any O(machine word size) operation would be atomic.  And all of 
these
> could be implemented using compare-exchange instructions, which are
> available on quite a variety of multiprocessor CPU architectures.
> STLPort already provides an implementation of 
atomic_increment/decrement
> for Sparc machines (stlport/stl/_sparc_atomic.h) and many other CPUs
> which provide "compare and exchange" could also be made to work 
within
> this framework.  It would bridge the gap between the CPU-specific
> instructions and the general concept which is rather portable.
> 
> I'm not sure if this was discussed already and considered too
> error-prone.  But if not, and it's not to be considered error-
prone, it
> could be very useful for other purposes besides the current 
shared_count
> of smart pointers.

Yes, it was discussed, and *I* determined (against the wishes of 
several) that it was too error prone.  I felt that the operations 
were only useful for generating synchronization primitives, which I'd 
hoped to cover with the library, or for ref-counting.  The ref-
counting usage would be safer implemented with a simple ref-count 
concept then to expose all of the atomic operations where too many 
novices misuse the operations.

Like I said, though, that decision is unpopular and I'll likely have 
to re-think the decision at some point.

Bill Kempf