[libdispatch-dev] lib dispatch worker threads may loop depending on compiler optimization

Daniel A. Steffen dsteffen at apple.com
Mon Sep 12 12:40:15 PDT 2011

On Sep 9, 2011, at 10:30 AM, Paolo Bonzini wrote:

> On 09/09/2011 05:49 PM, Dave Zarzycki wrote:
>>>> No, it didn't.  Really, believe me, unlike you I can follow GCC
>>>> development.;)
>> If putting asm("" ::: "memory") before __sync_lock_test_and_set()
>> fixes the bug, then that proves that GCC no longer considers
>> __sync_lock_test_and_set() to be a full barrier.
> It is not "no longer".  It never did, and it worked by chance.
> It doesn't even consider it an acquire barrier, in fact.  Even for a cmpxchg or any other sync builtin, the barrier semantics remain in the assembly, but are lost for the compiler midway through the compilation.

that loss sounds like a clear bug in GCC to me (it doesn't make sense for the __sync builtins not to be compiler barriers given that they are defined to generate memory barrier instructions), is there a reference to this issue that we can track ?


More information about the libdispatch-dev mailing list