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

[Benjamin LaHaise]

On Thu, Apr 07, 2005 at 12:43:02PM +0100, Christoph Hellwig wrote:
>  - switch all current semaphore users that don't need counting semaphores
>    over to use a mutex_t type.  For now it can map to struct semaphore.
>  - rip out all existing complicated struct semaphore implementations and
>    replace it with a portable C implementation.  There's not a lot of users
>    anyway.  Add a mutex_t implementation that allows sensible assembly hooks
>    for architectures instead of reimplementing all of it
>  - add more features to mutex_t where nessecary

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:

	00_mutex.diff	- Introduces the basic mutex abstraction on top 
			  of the existing semaphore implementation.
	01_i_sem.diff	- Converts all users of i_sem to use the mutex 
			  abstraction.
	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.
	sem-test.c	- A basic stress tester for the mutex / semaphore.

I'm still not convinced that introducing the mutex type is the best 
approach, especially given the history of the up()/down() implementation.

On the aio side of things, I introduced the owner field in the mutex (as 
opposed to the flag in Trond's iosem) for the next patch in the series to 
enable something like the following api:

	int aio_lock_mutex(struct mutex *lock, struct iocb *iocb);

	...generic_file_read....
	{
		ret = mutex_lock_aio(&inode->i_sem, iocb);
		if (ret)
			return ret; /* aio_lock_mutex can return -EIOCBQUEUED */
		...
		mutex_unlock(&inode->i_sem);
	}

mutex_lock_aio will attempt to take the lock if the iocb is not the owner, 
otherwise it returns immediately (ie ->owner == iocb).  This will allow for 
code paths that support aio to follow a fairly similar coding style to the 
synchronous io path.

More next week...

		-ben
-- 
"Time is what keeps everything from happening all at once." -- John Wheeler
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/