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

[Davide Libenzi]

On Wed, 4 Feb 2009, Andrew Morton wrote:

> On Wed, 4 Feb 2009 14:58:39 -0800 (PST)
> 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.
> 
> Would be nice to spell out what "a sempahore-like way" is.

Counter-based resource access? Where a "wait()" returns immediately by 
decrementing the counter by one, if counter is greater than zero. 
Otherwise will wait. And where a "post(count)" will add count to the 
counter releasing the appropriate amount of waiters.
If eventfd the "post" (write) part is fine, while the "wait" (read) does 
not dequeue 1, but the whole counter value.




> > Simple test here:
> > 
> > http://www.xmailserver.org/eventfd-sem.c
> > 
> > 
> > Signed-off-by: Davide Libenzi <davidel@xxxxxxxxxxxxxxx>
> > 
> > +/*
> > + * CAREFUL: Check include/asm-generic/fcntl.h when defining
> > + * new flags, since they might collide with O_* ones. We want
> > + * to re-use O_* flags that couldn't possibly have a meaning
> > + * from eventfd, in order to leave a free define-space for
> > + * shared O_* flags.
> > + */
> > +#define EFD_SEMAPHORE (1 << 0)
> >  #define EFD_CLOEXEC O_CLOEXEC
> >  #define EFD_NONBLOCK O_NONBLOCK
> >  
> > +#define EFD_SHARED_FCNTL_FLAGS (O_CLOEXEC | O_NONBLOCK)
> > +#define EFD_FLAGS_SET (EFD_SHARED_FCNTL_FLAGS | EFD_SEMAPHORE)
> 
> How would you recommend that userspace determine whether its kernel
> supports this feature, bearing in mind that someone might backport this
> patch into arbitrarily earlier kernel versions?
> 
> What should be userspace's fallback strategy if that support is not
> present?

#ifdef EFD_SEMAPHORE, maybe?



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