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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
