Anthony Williams wrote:
John Maddock <john <at> johnmaddock.co.uk> writes:
Just a couple of quick questions/comments regarding the use of _ReadWriteBarrier in the latest Boost.Thread code:
First up _ReadWriteBarrier is a VC++ compiler intrinsic: it's not supported by the Borland or MingW compilers, so these fail to link with unresolved externals to _ReadWriteBarrier. Can interlocked_read_acquire be written in terms of InterlockedCompareExchange(pointer, 0, 0) and InterlockedCompareExchangePointer(pointer-to-pointer, 0, 0) in these cases?
Yes, that's top of my list for this morning.
_ReadWriteBarrier stops the compiler from reordering. Going to a non-intrinsic InterlockedCompareExchange will also have this effect, but it might be possible to achieve it in another (cheaper) compiler-specific way; __asm__ ( :::"memory" ) is the GCC equivalent. Borland may already not reorder across a volatile read; this needs to be tested.