John Torjo <john.lists@torjo.com> 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).