[lkml]   [2009]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch/rfc] eventfd semaphore-like behavior
On Wed, 4 Feb 2009 14:58:39 -0800 (PST)
Davide Libenzi <> 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.

> Simple test here:
> Signed-off-by: Davide Libenzi <>
> +/*
> + * 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)

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

 \ /
  Last update: 2009-02-05 00:07    [W:0.079 / U:3.136 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site