Re: [boost] Re: detail::atomic_counter

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-11-28 13:21:18

From: <williamkempf_at_[hidden]>
> > 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.