Re: [PATCH 2.5.64] Real-time futexes (priority inheritance/protection/robust support) take 4
Ulrich Drepper <[email protected]>
| Newsgroups | gmane.comp.lib.phil |
|---|---|
| Organization | Red Hat, Inc. |
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Inaky Perez-Gonzalez wrote: > - Does not modify original futexes - a new interface is added This is the killer. If it's not the same futex interface which is used it is not possible to use the non-rt version of the libpthread and the rt version on the same system. The whole thing is complicated by statically binaries. The problem is obvious: what do you do for mutex/condvars/barriers/etc which are in shared memory and created with the pshared bit set? If it is not possible to use the same futex kernel interface, how would you select the right kernel interface to use? At the side of the process(es) which did not create the sync object there is no indication whatsoever whether the object is in shared memory or not. Therefore, any solution must fit seemlessly into the existing futex interface. It might be possible to have the function call which actually initializes the object to do some more work and tell the kernel something. But if the static initializers are used not even this is possible. For pshared object it is possible since there is no static initializer to create such objects. If you insist on not having a unified object the only possibility is to have separate libpthreads. Because of the confusion this creates and the support nightmare I strongly oppose this but of course cannot prevent it from happening in a separate project. - -- - --------------. ,-. 444 Castro Street Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA Red Hat `--' drepper at redhat.com `--------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+e/7a2ijCOnn/RHQRAvK5AJwJhCncd62IMJu74SZcL/uzGBPgLACgllCr ZQXr0dtrV0KXL0/+1LHThnE= =5kQy -----END PGP SIGNATURE-----