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

[Jordan K. Hubbard]

On Sep 12, 2011, at 12:40 PM, Daniel A. Steffen wrote:

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

Seeing as how gcc (outside of Apple) doesn't even support blocks, which I think we all agree are somewhat fundamental to GCD's ease-of-use, is there any real benefit to trying to grapple with gcc build issues in any case?  I have a hard time seeing the point of creating a build of libdispatch which only supports the _f() variants, in other words, and if the user is already essentially forced to use clang in order to truly benefit from libdispatch, then why not make the bootstrapping of clang on each given target platform a prerequisite?  (I googled for "clang for windows" and got a fair number of hits, btw, though I don't know how fully baked that port is yet).   Just a thought!

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/libdispatch-dev/attachments/20110912/5d0b8919/attachment.html>