Re: second, bigger problem with private futexes

[Eric Dumazet <dada1@cosmosbay.com>]

Eric Dumazet a écrit :
> Ulrich Drepper a écrit :
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Eric Dumazet wrote:
> > > Do you mean POSIX allowed to mix PROCESS_PRIVATE and PROCESS_SHARED
> > > condvar and mutexes ? Seems silly to me :(
>
> > Don't judge what you don't understand.
>
> Yes, I kindly apologise for this crime.
>
>  > If all waiters are always in one
> > process but the notifiers can be in different processes, this setup
> > might make a lot of sense.
>
> Thanks for providing this information.
>
> I assume in this case the condvar is PSHARED, while mutex could be/is 
> PRIVATE ?
>
> I wonder how old (assuming all shared) code could work, since the 
> notifier would call FUTEX_CMP_REQUEUE giving a target address outside of 
> this process vm ?
>
> My understanding (probably bad, since I know nothing about POSIX as you 
> mentioned)
>
> - Old code could not use FUTEX_CMP_REQUEUE if mutex was private.
> -> Old code was using a normal FUTEX_WAKE in this case.
>
> So I repeat my question : Should we really add yer another futex command 
> in kernel for a corner case ?

Reading this I realize it's confusing... :(

Because a process issuing a futex() syscall cannot point to another process vm 
(without giving more information than just a virtual address), I do think :

1) pthread_cond_broadcast() SHOULD use FUTEX_CMP_REQUEUE if :

condvar & mutex are PSHARED

2) pthread_cond_broadcast() MUST use FUTEX_CMP_REQUEUE_PRIVATE if :

condvar & mutex are PRIVATE

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.

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. -> a FUTEX_WAKE is necessary (no REQUEUE optim)
I guess it's OK performance wise since the notifier in this case probably 
doesnt hold a lock on the mutex. And probably old glibc was doing same thing, 
since the mutex address stored in condvar was possibly in another vm, and 
notifier had the same problem.


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/