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