lkml.org 
[lkml]   [2006]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2006-06-13 10:39    [W:3.529 / U:0.352 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site