Re: [boost] [thread] Use of _ReadWriteBarrier

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-10-08 08:52:08

"Peter Dimov" <pdimov_at_[hidden]> writes:

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

Totally agreed. The easiest change to make mingw and Borland non-broken was to
use ICE, but it is definitely overkill if there's a cheaper way.

All that's need here is a compiler barrier; I couldn't find an equivalent in
the Borland docs this morning, but that doesn't mean there isn't one. Does
__asm__ ( :::"memory" ) work on mingw? If so, I'll use that rather than ICE
for mingw.

Anthony
-- 
Anthony Williams
Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL