imports and python locking

Neal Becker ndbecker2 at gmail.com
Fri Jul 22 01:22:33 BST 2005


Martin Pool wrote:

> On 21 Jul 2005, Denys Duchier <duchier at ps.uni-sb.de> wrote:
>> Martin Pool <mbp at sourcefrog.net> writes:
>> 
>> > The attached c file demonstrates the problem when compiled with "gcc
>> > -lpthread".  Compiling with -march=686 (in the hope of using cmpxchg or
>> > something) does not help.  Run it under strace and observe thousands of
>> > pointless futex calls.
>> 
>> all I see are FUTEX_WAKE operations. AIUI, there's no way around those as
>> the
>> queue associated with a futex lives in the kernel.  What we don't see are
>> FUTEX_WAIT operations (all sem_wait are non-contended and take place only
>> in userspace).
> 
> According to the futex man page, there should only be a FUTEX_WAKE call
> when there are other processes waiting for the resource:
> 
>        Waiting on a futex, to ’down’ it, is the reverse
>        operation. Atomically decrement the counter and check if it
>        changed to 0, in which case the operation is done and the futex
>        was uncontended. In all other circumstances, the process should
>        set the counter to -1 and request that the kernel wait for
>        another process to up the futex. This is done using the
>        FUTEX_WAIT operation.
> 
> But here is some remarkable information: if you build the test case
> -static, then the futex wakes don't happen!
> 

Sounds strange.  I suggest reporting this to glibc maintainers.





More information about the bazaar mailing list