RE: [boost] [shared_ptr] Interlocked* - possible bug?

From: Ben Hutchings (ben.hutchings_at_[hidden])
Date: 2004-09-22 11:03:58

John Torjo <john.lists_at_[hidden]> wrote;
> Hi Peter,
> 
> I think there is a bug in your Interlocked* implementation of 
> shared_ptr
>   (http://www.pdimov.com/cpp/shared_count_x86_exp2.hpp).
> 
> In atomic_read you have:
> inline long atomic_read(long volatile const  & value)
> {
>      return value;
> }
> 
> I don't believe this is thread-safe.
> In order to make sure you're receiving the latest value,

I don't believe that's actually important.  What's important is that
shared memory accesses are not reordered.

The "volatile" should prevent the compiler from reordering the read
with respect to other volatile access, but that leaves the question
of whether the processor may reorder the read with respect to other
shared memory access.

I think the answer is that it cannot change the order of an
atomic_read and an atomic update, assuming that the latter uses an
Interlocked* operations which includes a full memory barrier, but
unfortunately it would be able to change the order of two
atomic_reads.

(Unfortunately www.pdimov.com does not want to talk to me so I haven't
been able to read the rest of the code.)

> I assume you could do something like:
> 
> inline long atomic_read(long volatile & value)
> {
>      const int IMPOSSIBLE_VALUE = -100;
>      return InterlockedCompareExchange(&value, IMPOSSIBLE_VALUE,
> IMPOSSIBLE_VALUE);
> }
> 
> Am I missing something?

That looks reasonable, yet I feel that there should be a better way
to do this!  Note that InterlockedCompareExchange is not available
in early Win32 implementations (NT 3.x and Win95).