Messages in this thread |  | | | Date | Tue, 13 Jun 2006 01:06:28 +0900 (JST) | | Subject | Re: NPTL mutex and the scheduling priority | | From | Atsushi Nemoto <> |
| |
On Mon, 12 Jun 2006 17:24:28 +0200, Sébastien Dugué <sebastien.dugue@bull.net> wrote: > > > you want to use the PI futexes that are in 2.6.17-rc5-mm tree > > > > Even for normal mutices pthread_mutex_unlock and > > pthread_cond_{signal,broadcast} is supposed to honor the RT priority and > > scheduling policy when waking up: > > http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_trylock.html > > "If there are threads blocked on the mutex object referenced by mutex when > > pthread_mutex_unlock() is called, resulting in the mutex becoming available, > > the scheduling policy shall determine which thread shall acquire the mutex." > > and similarly for condvars. > > "Use PI" is not a valid answer for this. > > Really FUTEX_WAKE/FUTEX_REQUEUE can't use a FIFO. I think there was a patch > > floating around to use a plist there instead, which is one possibility, > > another one is to keep the queue sorted by priority (and adjust whenever > > priority changes - one thread can be waiting on at most one futex at a > > time). > > > > The patch you refer to is at > http://marc.theaimsgroup.com/?l=linux-kernel&m=114725326712391&w=2
Thank you all. I'll look into PI futexes which seems the right direction, but I still welcome short term (limited) solutions, hopefully work with existing glibc. I'll look at the plist patch.
--- Atsushi Nemoto - 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/
|  |