[lkml]   [2002]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject: Re: [PATCH] Lightweight userspace semaphores... 
In-reply-to: Your message of "Sun, 24 Feb 2002 17:23:59 -0800."

In message <> you wri
> On Mon, 25 Feb 2002, Rusty Russell wrote:
> >
> > Bugger. How about:
> >
> > sys_sem_area(void *pagestart, size_t len)
> > sys_unsem_area(void *pagestart, size_t len)
> >
> > Is that sufficient? Is sys_unsem_area required at all?
> The above is sufficient, but I would personally actually prefer an
> interface more like
> fd = sem_initialize();
> mmap(fd, ...)
> ..
> munmap(..)
> which gives you a handle for the semaphore.

No no no! Implemented exactly that (and posted to l-k IIRC), and it's
*horrible* to use.

> Note that getting a file descriptor is really quite useful - it means that
> you can pass the file descriptor around through unix domain sockets, for
> example, and allow sharing of the semaphore across unrelated processes
> that way.

First, fd passing sucks: you can't leave an fd somewhere and wait for
someone to pick it up, and they vanish when you exit. Secondly, you
have some arbitrary limit on the number of semaphores. Thirdly,
someone has to own them.

Consider tdb, the Trivial Database. There is no "master locking
daemon". There is no way for the first opener (who then has to create
the semaphores in your model) to pass them to other openers: this is a

With this interface, I can use them on the stack with clone().

Most importantly, I can place the semaphores in a file and have them

lock(1), unlock(1) => fast semaphores in shell scripts!
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
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-03-22 13:24    [W:0.054 / U:4.844 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site