[lkml]   [2006]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] 2.6.16 - futex: small optimization (?)
Ulrich Drepper a écrit :
> There are no such situations anymore in an optimal userlevel
> implementation. The last problem (in pthread_cond_signal) was fixed
> by the addition of FUTEX_WAKE_OP. The userlevel code you're looking
> at is simply not optimized for the modern kernels.

I think there is a misunderstanding here.

FUTEX_WAKE_OP is implemented to handle simultaneously more than one
futex in some specific situations (such as pthread_cond_signal).

The scenario I've described occurred in futex_wake, futex_wake_op and
futex_requeue and is _independent_ of the userlevel code.

All these functions call wake_futex, and then wake_up_all, with the
futex_hash_bucket lock still held.

If the woken thread is immediately scheduled (in wake_up_all), and only
in this case (because of a higher priority, etc), it will try to take
this lock too (because of the "if (lock_ptr != 0)" statement in
unqueue_me), causing two task-switches to take this lock for nothing.

Otherwise, it will not: lock_ptr is set to NULL just after the
wake_up_all call)

This scenario happens at least in pthread_cond_signal,
pthread_cond_broadcast and probably all pthread_*_unlock functions.

The patch I've proposed should, at least in theory, solve this. But I'm
not sure of the correctness...

Pierre P.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-03-29 15:20    [W:0.076 / U:1.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site