lkml.org 
[lkml]   [2007]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: first little problem with private futexes
    Ulrich Drepper a écrit :
    > On 5/20/07, Eric Dumazet <dada1@cosmosbay.com> wrote:
    >> > 1. do nothing, always use the shared futexes. Not very attractive IMO
    >>
    >> Why do you find this non attractive ?
    >>
    >> How is it performance critical ?
    >
    > You should know better than any other that the problem is not that the
    > problem itself is the only one affected. If threads terminate all
    > other programs and threads are affected since the global locks for the
    > shared futexes are needed. That's the case I'm concerned about. It's
    > not really about a single app creating many many threads over and over
    > again. It's about many apps which do use threads (and that number
    > will have to rise) starts and stop threads at a reasonable rate. It's
    > just one more unnecessary point of contact between concurrently
    > running apps.

    Well, current private futex code still use global locks (one common hash table
    were all waited futexes are queued, private or shared)

    'Only' mmap_sem and inode/mm refcounter inc/dec are avoided.

    My proposal of having separate namespace was hold, in order to get the
    'private futexes' accepted in kernel.

    So for the moment, I am not sure glibc should try to optimize CLEARTID operation.


    -
    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: 2007-05-20 21:17    [W:0.021 / U:101.648 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site