![]() |
Boost : |
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk