[lkml]   [2005]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Add support for semaphore-like structure with support for asynchronous I/O
On Tue, Apr 05, 2005 at 11:46:41AM -0400, Benjamin LaHaise wrote:
> On Mon, Apr 04, 2005 at 01:56:35PM -0400, Trond Myklebust wrote:
> > IOW: the current semaphore implementations really all need to die, and
> > be replaced by a single generic version to which it is actually
> > practical to add new functionality.
> I can see that goal, but I don't think introducing iosems is the right
> way to acheive it. Instead (and I'll start tackling this), how about
> factoring out the existing semaphore implementations to use a common
> lib/semaphore.c, much like lib/rwsem.c? The iosems can be used as a
> basis for the implementation, but we can avoid having to do a giant
> s/semaphore/iosem/g over the kernel tree.

Note that iosem is also a total misowner, it's not a counting semaphore
but a sleeping mutex with some special features.

Now if someone wants my two cent on how to resolve the two gazillion different
implementations mess:

- 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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-07 13:47    [W:0.131 / U:14.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site