Messages in this thread |  | | | Date | Mon, 21 May 2007 21:55:40 +0200 | | From | Eric Dumazet <> | | Subject | Re: second, bigger problem with private futexes |
| |
Ulrich Drepper a écrit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Eric Dumazet wrote: >> 3) if condvar is PRIVATE and mutex is SHARED, a FUTEX_WAKE_PRIVATE >> should be done. (and loose the REQUEUE optim) >> Yes we could add a special futex primitive for this special case. But I >> cannot see how a program could use such a construct. > > Very easily: mutexes are often created independently from the condvars > and they are used for many things. Maybe a program is even creating all > mutexes as shared to be ready for all situations. Normally doing this > is no big problem, the performance penalties are minimal. > > >> 4) if condvar is SHARED and mutex is private, we have a *problem*, >> because the process doing the broadcast() can be in another mm. So a >> requeue is not possible at all. > > It is if we can specify the owner of the mutex. I.e., the PID.
well, then we have a refcounting issue on pid , or problem in pid reuse.
> > But yes, this case is extremely ugly. > > > The problem is that all these cases worked nice so far. They all had > the same good performance. Now we are severely penalizing code which > mismatches condvar and mutex shared attributes. There is a good reason > why we introduced FUTEX_CMP_REQUEUE, the benefits in certain programs is > huge.
This analysis seems unfair to me, after a quick reading of glibc code.
Right now, glibc cannot use FUTEX_CMP_REQUEUE if condvar is pshared.
/* Do not use requeue for pshared condvars. */ if (cond->__data.__mutex == (void *) ~0l) goto wake_all; So how introducing private futexes is penalizing this case ?
Fact is that if condvar is pshared, we *cannot* use CMP_REQUEUE since threads doing the broadcast() can be in a separate process and virtual address of mutex of waiting threads could point to unrelated memory.
Thanks
- 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/
|  |