Re: [patch/rfc] eventfd semaphore-like behavior

[Davide Libenzi]

On Mon, 9 Feb 2009, Michael Kerrisk wrote:

> On Thu, Feb 5, 2009 at 11:58 AM, Davide Libenzi <davidel@xxxxxxxxxxxxxxx> wrote:
> > People started using eventfd in scnarios where before where using pipes.
> > Many of them use eventfds in a semaphore-like way, like they were before
> > with pipes. The problem with eventfd is that a read() on the fd returns
> > and wipes the whole counter, making the use of it as semaphore a little
> > bit more cumbersome. You can do a read() followed by a write() of
> > COUNTER-1, but IMO it's pretty easy and cheap to make this work w/out
> > extra steps. This patch introduces a new eventfd flag that tells eventfd
> > to only dequeue 1 from the counter, allowing simple read/write to make it
> > behave like a semaphore.
> > Simple test here:
> >
> > http://www.xmailserver.org/eventfd-sem.c
> >
> >
> > Signed-off-by: Davide Libenzi <davidel@xxxxxxxxxxxxxxx>
> 
> Tested-by: Michael Kerrisk <mtk.manpages@xxxxxxxxx>
> 
> Applied this patch against 2.6.29-rc3, and it works as I would expect.
> 
> 
> A question or two.... This change is rather specific to a single use
> case, so I wonder
> 
> a) Are there use cases that require the ability to read an arbitrary
> number of units off the eventfd -- i.e., read N units off the eventfd,
> rather than just 1?

Not that I can think of.


> b) Is it desirable to be able to toggle the EFD_SEMAPHORE behavior on
> and off for an eventfd?

This I'd say no. A synchronization entity in all decently sane sw design 
I've ever seen, remains the same in behaviour and it is never changed 
runtime to behave in different ways.


> It's difficult to see how these use cases could be accommodated in the
> current API, but I just thought it worth raising the ideas.

Since read/write semantics cannot be changed (besides, like the semaphore 
change, for the amount of "data" dequeued), deeper changes to the 
interface will have to go via ioctl(). But I don't see any reason to go 
that way ATM.



- Davide


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