[lkml]   [2006]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: NPTL mutex and the scheduling priority
    On Mon, Jun 12, 2006 at 02:23:28PM +0200, Arjan van de Ven wrote:
    > On Mon, 2006-06-12 at 17:10 +0900, Atsushi Nemoto wrote:
    > > # This is a copy of message posted libc-alpha ML. I want to hear from
    > > # kernel people too ...
    > >
    > > Hi. I found that it seems NPTL's mutex does not follow the scheduling
    > > parameter. If some threads were blocked by getting a single
    > > mutex_lock, I expect that a thread with highest priority got the lock
    > > first, but current NPTL's behaviour is different.
    > \
    > 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:
    "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

    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-06-12 14:46    [W:0.021 / U:10.516 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site