Re: [boost] detail::atomic_counter

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

--- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
 > From: Itay Maman <gtpaw_at_w...>
 > > --- 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'll let Peter speak to what the philosophy is, but I believe
 > atomic_counter should be as simple and fast as possible, doing
 > one thing and doing it well.  If you also want an atomic_integer
 > then go for it.

suggested copy assignment/construction is not supposed to affect 
atomic_counter's efficiency at all.

On the other hand,  modifying the ++/-- operator to return the updated 
value under all system, _does_ have a considerable time cost, which is 
valid argument against it.

Itay.