RE: [PATCH 2.5.64] Real-time futexes (priority inheritance/protec tion/robust support) take 4

>For mutexes: two options:
>
>1. on _init time, you determine what interface is to be used 
>and set a bit
>or setup a function pointer in the mutex structure that indicates which
>interface to use for all the call redirection to be done properly (for
>example, pthread_mutex_t.__data.__kind). 

I think option 1 makes more sense. From POSIX standards, mutex's protocol is
settled at init time and cannot be changed anymore. Therefore, if a mutex is
inited by a mutexattr_t using PTHREAD_PRIO_{INHERIT|PROTECT} protocol, it
will always be redirected to use the new interface, i.e. rtfutex. The
overhead to original mutex operation can be limited to just an extra
comparison, quite close to nil.

>The trick here is to get it right
>so that (a) overhead is close to nil [I know, understand and 
>agree on you being anal about this - me too] (b) it is correctly 
>propagated/shared. If we are using shared memory to share the mutex, 
>well, the other guy will see the
>same bit in pthread_mutex_t [in this case is where a function 
>pointer does
>not work, cross that out] and do the proper call forwarding. 

>2. or use the rtfutex interface all the time on arches that 
>support atomic
>CAS instead of having to switch - falling back to the futex interface
>[compile time]. This would also depend on if we can get good 
>performance out
>of the rtfutex, close to that of the futex. I think so, 
>although I still
>haven been able to measure it properly.
>