Re: detail::atomic_counter

From: williamkempf_at_[hidden]
Date: 2001-11-28 11:50:20

--- In boost_at_y..., Mattias Flodin <flodin_at_c...> wrote:
> 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.

Bill Kempf