Re: Why Semaphore Hardware-Dependent?

[Nick Piggin <nickpiggin@yahoo.com.au>]

Arjan van de Ven wrote:
> On Mon, 2006-08-28 at 03:22 +0800, 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
>>seems the semaphore definitions classified into two major categories.
>>The main deference is whether there is a member variable _sleeper_.
> 
> 
> btw semaphores are a deprecated construct mostly; mutexes are the way to
> go for new code if they fit the usage model of mutexes. And mutexes are
> indeed generic (with a architecture hook to allow a specific operation
> to be optimized using assembly)

That's true, although rwsems are still very important for mmap_sem (if
nothing else). There is not yet an rw/se-mutex.

rwsem is another place that has a huge proliferation of assembly code.
I wonder if we can just start with the nice powerpc code that uses
atomic_add_return and cmpxchg (should use atomic_cmpxchg), and chuck
out the "crappy" rwsem fallback implementation, as well as all the arch
specific code?

That would seem to be able to rid us of vast swaths of tricky asm, and
also double the test coverage of the out of line lib/ code. Should still
generate close to optimal code on i386. The only architectures that might
slightly care are those who's atomics hash to locks (in that case, you'd
really rather take a lock in the rwsem's cacheline than a random atomic
lock... but I don't think incredible parisc/sparc SMP performance is
worth the current situation!)

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com