From: williamkempf_at_[hidden]
Date: 2001-11-28 16:59:36
--- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> From: <williamkempf_at_h...>
> > > 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.
And are rarely (if ever) thread safe. So you're not helping anybody
by duplicating the interface of raw integer types here, IMHO.
Bill Kempf