Re: detail::atomic_counter

From: williamkempf_at_[hidden]
Date: 2001-11-29 09:54:05

--- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> From: <williamkempf_at_h...>
> > --- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> > > From: <williamkempf_at_h...>
> > > > ...  What is being created is an atomic  counter, 
> > > > not an atomic integer, and as a counter there's little need 
for any 
> > > > information other than < 0, == 0, > 0.  So instead of using 
the ++ 
> > > > and -- operators I'd define increment() and decrement() 
methods and 
> > > > gaurantee only the above comparisons to 0.  This gives you 
optimal 
> > > > portability and should cover all real needs.
> > > 
> > > The advantage of using ++ and -- is that raw integer types 
support them.
> > 
> > And are rarely (if ever) thread safe.  So you're not helping 
anybody 
> > by duplicating the interface of raw integer types here, IMHO.
> 
> And lots of code doesn't need to be thread safe.  So it's nice if
> raw integers can satisfy our generic counter requirements.  One
> alternative might be free increment and decrement functions that
> are specialized for integers and for atomic_counter.

This is one case where I'd be perfectly happy with free functions (in 
fact the atomic_t class that was originally being toyed with for 
Boost.Threads used free functions for the reasons you're pointing out 
now).  I just don't like the mathematic operators here, since they 
suggest functionality that can't/won't exist.

Bill Kempf