Re: detail::atomic_counter

From: williamkempf_at_[hidden]
Date: 2001-11-28 16:59:36

--- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> From: <williamkempf_at_h...>
> > > On Sat, 17 Nov 2001, Carl Daniel wrote:
> > > > It's probably be worth noting that 
InterlockedIncrement/decrement 
> > on NT 3.5.1 and Windows 95 does not necessarily return
> > > > the new count.  It returns 0 if the the result was 0, a 
negative 
> > number if the count was negative, a positive number if
> > > > the count was positive.
> > > 
> > > Right. If worse comes to worse, it is possible to get around 
this by
> > > implementing those functions in inline assembler, using the 
lock 
> > prefix on
> > > the IA-32 inc instruction (something similar exists for Alpha 
> > processors,
> > > and IA-64 is not an issue since there are no pre-Windows XP
> > > implementations for it).  But as long as this is a detail class 
it 
> > is
> > > undoubtedly better to just have the counter provide the least 
common
> > > denominator of the platforms instead. That is, something like an
> > > increment() and a decrement() function that provide the same 
return 
> > value
> > > semantics as the Interlocked* functions on pre-NT4 platforms.
> > 
> > There's a reason why NT 3.5 and Win95 don't work this way.  NT 
3.5 
> > and Win95 support hardware on which the above suggested ASM code 
> > won't work.  Sooo... I don't think taking the ASM approach is the 
> > correct solution here.  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.

Bill Kempf