Boost logo

Boost :

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
> 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
> 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
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at