Messages in this thread |  | | | Date | Sun, 20 May 2007 21:13:44 +0200 | | From | Eric Dumazet <> | | Subject | Re: 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/
|  |