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
> > > >--a; // atomic decrement, returns the new value (by value, type
> > > >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
> > is: "it's just like the good old long type, except you need not
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk