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.844 / U:0.076 seconds]
©2003-2011 Jasper Spaans. Advertise on this site