Re: [boost] detail::atomic_counter

From: Itay Maman (gtpaw_at_[hidden])
Date: 2001-11-19 07:07:40

--- In boost_at_y..., Jesse Jones <jesjones_at_h...> wrote:
 > At 5:18 PM +0200 11/17/01, Peter Dimov wrote:
 > >In order to make shared_ptr thread safe (w.r.t. reference counting) we need
 > >an atomic_counter type, with the following operations defined:
 > >
 > >atomic_counter a(n); // n is the initial value, convertible to 'long'
 > >++a; // atomic increment, returns the new value (by value, type 'long')
 > >--a; // atomic decrement, returns the new value (by value, type 'long')
 > >a; // convertible to long, atomic read (to support use_count() and 
unique())
 >
 > The copy semantics need to be ironed out. In the code that was posted
 > the Windows version can be copied with no problems. The pthreads
 > version can also be copied, but I think bad things will happen
 > because the mutex is bit-wise copied. Simply disabling copying may be
 > OK.
 >
 >    -- Jesse

I don't agree with you. I think that atomic_counter's underlying philosophy 
is: "it's just like the good old long type, except you need not protect it 
when multiple threads are involved". I tried to apply this guideline on the 
following piece of code:

atomic_counter a(5);
++a;
atomic_counter b(a);
++b;

Since the equivalent long code (long a(5); ++a; long b(a); ++b;) yields 
a==6, b==7, I belive that most developers expect the atomic_counter code to 
generate the same results. Hence, the copy operations (either copy 
construction or copy assignment) should be supported, where the 
implementation copies the 'other' object's value, but not its mutex.

Itay.