Re: Why Semaphore Hardware-Dependent?

[Andi Kleen <ak@suse.de>]

On Sunday 27 August 2006 21:22, Dong Feng wrote:
> Why can't we have a hardware-independent semaphore definition while we
> have already had hardware-dependent spinlock, rwlock, and rcu lock? It

We probably could yes, if up/down were out of lined. The only
reason it is assembly code is that it uses still funky assembly
to get a fast uncontended fast path. Since out of lining
worked for spinlocks it will likely work for semaphores too.

> seems the semaphore definitions classified into two major categories.
> The main deference is whether there is a member variable _sleeper_.
> Does this (optional) member indicate any hardware family gene?

AFAIK the normal semaphores all work basically the same over the
architectures, just the calling conventions are different. If it was
pure out of line C that wouldn't be a problem anymore.

rwsems don't -- there are two flavours: a generic spinlock'ed one and a 
complicated atomic based one that only works on some architectures. 
As far as I know nobody has demonstrated a clear performance increase
from the first so it might be possible to switch all to the generic
implementation.

If you're interested in this you should probably do patches and benchmarks.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/