Re: [RFC/PATCH] FUSYN Realtime & robust mutexes for Linux, v2.3.1

[Ulrich Drepper <drepper@redhat.com>]

Andrew Morton wrote:

> How large is the slowdown, and on what workloads?

The fast path for all locking primitives etc in nptl today is entirely
at userlevel.  Normally just a single atomic operation with a dozen
other instructions.  With the fusyn stuff each and every locking
operation needs a system call to register/unregister the thread as it
locks/unlocks mutex/rwlocks/etc.  Go figure how well this works.  We are
talking about making the fast path of the locking primitives
two/three/four orders of magnitude more expensive.  And this for
absolutely no benefit for 99.999% of all the code which uses threads.


> Passing the lock to a non-rt task when there's an rt-task waiting for it
> seems pretty poor form, too.

No no, that's not what is wanted.  Robust mutexes are a special kind of
mutex and not related to rt issues.  Lockers of robust mutexes have to
register with the kernel (i.e., the locking must actually be performed
by the kernel) so that in case the thread goes away or the entire
process dies, the mutex is unlocked and other waiters (other threads, in
the same or other processes) can get the lock.  This is very useful for
normal operations where mutexes are used inter-process.  This is the
part which is independent from rt but it also must not be the default
mode (i.e., normal pthread_mutex_t code must not be replaced) since it
is significantly slower.


The rest of the extensions like all the priority handling is not of
general interest.  POSIX describes how a thread's priority would be
temporarily raised if it holds a mutex which has a higher-priority
waiter.  But this is all functionality of a realtime profile and widely
not part of the normal implementation.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖