Messages in this thread | | | Date | Tue, 13 Jun 2006 10:39:54 +0200 | From | Pierre Peiffer <> | Subject | Re: NPTL mutex and the scheduling priority |
| |
Sébastien Dugué a écrit : > But maybe a better solution for condvars would be to implement > something like a futex_requeue_pi() to handle the broadcast and > only use PI futexes all along in glibc. > > Any ideas?
I'm currently thinking about it, and as far as I can see, it should be technically feasible but not obvious. In fact, PI-futex adds a rt-mutex behind each futex, when there are some waiters. Each waiter is then queued two times: once in the chain list of the hash-bucket, once in the (ordered) wait_list of the rt-mutex.
What we want, with a futex_requeue_pi, is a requeue of some tasks from (futex1, rt_mutex1) to (futex2, rt_mutex2), respecting the wait_list order of rt_mutex1.wait-list. => this needs something like a rt_mutex_requeue, and given an element of rt_mutex1.wait_list, we need to retrieve its futex_q to requeue it to the second hash-bucket chain (of futex2).
Moreover, we must take care of the case where the futex2 is not yet locked (i.e. has no owner): there is not yet a pi_state nor a rt_mutex associated with the futex2 ...
And during all of this, we must take care of several race conditions in several places.
I'll continue my investigation, but I really wonder if futex_requeue_pi will still be an "optimization" as it should be.
So comments from the experts are welcome ;-)
-- Pierre
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |