September 2011 - libdispatch-dev - lists.macosforge.org

Re: [libdispatch-dev] lib dispatch worker threads may loop depending on compiler optimization
by Paolo Bonzini 20 Sep '11

20 Sep '11

On 09/19/2011 06:32 PM, Joakim Johansson wrote: > <http://libdispatch.macosforge.org/trac/ticket/35#comment:10> Thanks. It turns out it is _not_ a bug in GCC at all, but in libdispatch. Compiling the .i file shows the following: movq %r13, %rax movq $1, 0(%r13) movq %r12, 16(%r13) #APP # 110 "/tb/builds/thd/sbn/2.4/src/thirdparty/libdispatch/197/src/src/queue_internal.h" 1 xchg %rax, 64(%rbx) # 0 "" 2 #NO_APP testq %rax, %rax movq %rbp, 24(%r13) movq $0, 8(%r13) je .L172 The APP/NO_APP markers signify that an asm is being used rather than sync builtins. Looking at the source code indeed reveals this... // GCC generates suboptimal register pressure // LLVM does better, but doesn't support tail calls // 6248590 __sync_*() intrinsics force a gratuitous "lea" instruction, with resulting register pressure #if 0 && defined(__i386__) || defined(__x86_64__) #define dispatch_atomic_xchg(p, n) ({ typeof(*(p)) _r; asm("xchg %0, %1" : "=r" (_r) : "m" (*(p)), "0" (n)); _r; }) #else #define dispatch_atomic_xchg(p, n) ((typeof(*(p)))__sync_lock_test_and_set((p), (n))) #endif ... which is missing parentheses like #if 0 && (defined(__i386__) || defined(__x86_64__)) The asm is wrong, because it doesn't have a clobber for "memory". That fixes the testcase. Paolo

2 1

lib dispatch worker threads may loop depending on compiler optimization
by Joakim Johansson 17 Sep '11

17 Sep '11

We just filed http://libdispatch.macosforge.org/trac/ticket/35 after sometimes encountering spinning worker threads when running under high load on multi-cpu machines. Various versions of gcc will optimize and reorder the code differently, but with 4.5.1 we run into this problem. Is this a fundamental problem with libdispatch itself that will rear it’s ugly head if/when the Mac OS X system compiler is changed in the future (to optimize more aggressively), or is it a bug in the gcc 4.5.1 optimizer? The Lion source code seems more or less unchanged here, so even if we tested this with the current r197 code base, the behavior should be the same when integrating the latest source drop. Thoughts? Thanks, Joakim

10 36

CFLite packages for Linux
by Mark Heily 03 Sep '11

03 Sep '11

Since there are some libdispatch tests that rely on CoreFoundation, I've ported CFLite to Debian Linux and released the unofficial binary and source packages here: http://mark.heily.com/project/CFLite I'm not able to run the tests yet because CFLite does not provide some of the necessary functions that libdispatch needs [1]. These functions are in CFRunLoop.c which is not built by default. I'll add it to the build and see what happens. - Mark [1] clang -DHAVE_CONFIG_H -I. -I../config -I.. -I.. -I../compat/libMachShims/include -Wall -g -fblocks -I../compat/libMachShims/include -I../compat/libkqueue/include -I../compat/libpthread_workqueue/include -MT dispatch_cf_main.o -MD -MP -MF .deps/dispatch_cf_main.Tpo -c -o dispatch_cf_main.o dispatch_cf_main.c dispatch_cf_main.c:38:3: warning: implicit declaration of function 'CFRunLoopPerformBlock' is invalid in C99 [-Wimplicit-function-declaration] CFRunLoopPerformBlock(CFRunLoopGetMain(), ... ^ dispatch_cf_main.c:38:25: warning: implicit declaration of function 'CFRunLoopGetMain' is invalid in C99 [-Wimplicit-function-declaration] CFRunLoopPerformBlock(CFRunLoopGetMain(), ... ^ dispatch_cf_main.c:38:45: error: use of undeclared identifier 'kCFRunLoopDefaultMode' CFRunLoopPerformBlock(CFRunLoopGetMain(), kCFRunLo... ^ dispatch_cf_main.c:56:2: warning: implicit declaration of function 'CFRunLoopRun' is invalid in C99 [-Wimplicit-function-declaration] CFRunLoopRun(); ^ 3 warnings and 1 error generated.

2 2