Anthony, 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? Secondly, I'm a bit confused why the barrier is *after* the read, shouldn't it be before? I'm not saying it should be, I just wondered :-) Thanks, John.
John Maddock wrote:
Secondly, I'm a bit confused why the barrier is *after* the read, shouldn't it be before? I'm not saying it should be, I just wondered :-)
The acquire semantics enforce that no load or store may be moved from behind to in front of the read, or the read be deferred until after a subsequent load or store accordingly. That's why the barrier has to be placed directly after the read. Timmo Stange
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.
Secondly, I'm a bit confused why the barrier is *after* the read, shouldn't it be before? I'm not saying it should be, I just wondered
As Timmo says, it's so nothing can be moved before the read. It's OK to move stuff into a critical section, but never out. Anthony
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.
"Peter Dimov" <pdimov@pdimov.com> 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
_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.
FWIW, Intel V10 on Windows seems not to implement _ReadWriteBarrier neither (at least we get linker errors there as well). Regards Hartmut
Hartmut Kaiser wrote:
FWIW, Intel V10 on Windows seems not to implement _ReadWriteBarrier neither (at least we get linker errors there as well).
Does its manual say something about reorderings across a volatile read or write? I think that giving volatile loads acquire semantics (and volatile stores release semantics) is an Intel invention later adopted by MSVC8, so it might already implement what we need.
"Hartmut Kaiser" <hartmut.kaiser@gmail.com> writes:
_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.
FWIW, Intel V10 on Windows seems not to implement _ReadWriteBarrier neither (at least we get linker errors there as well).
Yes, I spotted that. Hopefully this morning's fix will help there too. Does Intel v10 have an equivalent to _ReadWriteBarrier? 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
participants (5)
-
Anthony Williams -
Hartmut Kaiser -
John Maddock -
Peter Dimov -
Timmo Stange