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