Re: [RFC] Add support for semaphore-like structure with support for asynchronous I/O

[David Howells <dhowells@redhat.com>]

Benjamin LaHaise <bcrl@kvack.org> wrote:

> Oh dear, this is going to take a while.  In any case, here is such a 
> first step in creating such a sequence of patches.  Located at 
> http://www.kvack.org/~bcrl/patches/mutex-A0/ are the following patches:
> ...
> 	10_new_mutex.diff - Replaces the semphore mutex with a new mutex 
> 			    derrived from Trond's iosem patch.  Note that 
> 			    this fixes a serious bug in iosems: see the 
> 			    change in mutex_lock_wake_function that ignores 
> 			    the return value of default_wake_function, as 
> 			    on SMP a process might still be running while 
> 			    we actually made progress.

Can I suggest you don't use a wait_queue_t in your mutex? The way you've
implemented your mutex you appear to have to take spinlocks and disable
interrupts a lot more than is necessary.

You might want to look at how I've implemented semaphores for the frv arch:

	include/asm-frv/semaphore.h
	arch/frv/kernel/semaphore.c

On FRV disabling interrupts is quite expensive, so I've made my own simple
semaphores that don't need to take spinlocks and disable interrupts in the
down() path once the sleeping task has been queued[*]. These work in exactly
the same way as rwsems.

  [*] except for the case where down_interruptible() is interrupted.

The point being that since up() needs to take the semaphore's spinlock anyway
so that it can access the list, up() does all the necessary dequeuing of tasks
before waking them up.

David
-
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/