[lkml]   [2006]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH RT 0/2] futex priority based wakeup
    On Tue, 2006-05-16 at 06:36 -0400, Jakub Jelinek wrote:
    > On Thu, May 11, 2006 at 10:56:57AM +0200, S?bastien Dugu? wrote:
    > > Hm, I wonder what would be the effect of having the external mutex
    > > and __data.__lock use a PI futex and __data.__futex use a regular
    > > futex when the waiters on __data.__futex are requeued on the external
    > > mutex during a broadcast.
    > Well, either glibc can stop using requeue if the mutex is PI mutex (and use
    > the slower fallback), or kernel would need to handle requeueing from normal to
    > PI futex.

    Yes, or make the condvar use a PI futex and implement a
    futex_requeue_pi() and have glibc use that in the broadcast case. I
    think the requeue thing is a good idea and should not be dropped.

    > > > > But, there is a problem here - pthread_cond_{signal,broadcast} don't
    > > > > have any associated mutexes, so you often don't know which type
    > > > > of protocol you want to use for the internal condvar lock.
    > >
    > > Just a wild guess here, but in the broadcast or signal path, couldn't
    > > __data.__mutex be looked up to determine what protocol to use for the
    > > __data.__futex?
    > Not always.
    > Say if you do:
    > thread1 (low prio) thread2 (very high prio) thread3 (mid prio)
    > pthread_cond_signal (&cv)
    > # first use of cv in the program, no mutex has been ever used with this
    > # condvar
    > lll_mutex_lock (&cv->__data.__lock)
    > pthread_cond_wait (&cv, &pi_mutex)
    > lll_mutex_lock (&cv->__data.__lock)
    > use_all_CPU
    > # Then thread2 is stuck, waiting on thread1 which waits on thread3
    > At pthread_cond_signal enter time you don't know the type of associated
    > mutex, so you don't know which kind of internal lock to use.
    > It doesn't have to be the first use of cv in the program, similarly it can
    > be any pthread_cond_{signal,broadcast} called while there are no threads
    > in pthread_cond_*wait on that cv.

    OK, it makes sense now, thanks.


    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-05-18 10:49    [W:0.026 / U:5.660 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site