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

[Chris Friesen <cfriesen@nortelnetworks.com>]

Ulrich Drepper wrote:
> 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.

Just a small clarification.  (Rusty already touched on this briefly, but I think 
he made a mistake.)

If the arch has atomic compare-and-exchange, then the non-contended case is 
entirely userspace and no syscall is needed.  I don't think that the cmpxchg 
need be 64-bit.  From the OLS 2004 talk:

int vfulock_lock (&vfulock, flags, pid, &timeout) {
	unsigned old = VFULOCK_UNLOCKED;
	if (cmpxchg(vfulock,old,pid) != old) return 0;
	return SYSCALL(ufulock_lock,3,vfulock,flags,to);
}

That looks like a 32-bit cmpxchg to me.

Also, Inaky reported general operation about 10% slower than NPTL, but said that 
he wanted to fix that if possible.

Chris