[lkml]   [2009]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/2] eventfd: new EFD_STATE flag
On Thu, 27 Aug 2009, Michael S. Tsirkin wrote:

> Oh, I stopped pushing EFD_STATE since we have a solution.
> I am just trying to grok what does and what does not consititute a
> use-once addition, in your mind, and what does and what does not
> belong in eventfd. The reason atomic does not belong there and
> semaphore does is because one waits on semaphore but not
> on atomic? Is that it?

An atomic variable is not a synchronization interface.
Even if it'd come up that we really need an atomic variable abstraction
via an fd, this should not go via eventfd.
Yeah, maybe the name syncfd would have been better, but the very reason
why eventfd born was to allow KAIO to signal events to poll/select/epoll.
That first implementation was also usable as a mutex.
Then it was propsed to make eventfd to act as a semaphore too. Code was
trivial, a semaphore fitted the interface, and the abstraction was a
pretty damn known too. So it went in.
Yes, you could have implemented a semaphore with the existing eventfd, by
reading the counter and writing counter-1. But again, a semaphore was
something widely known and generic enough, and was fitting the bill.

- Davide

 \ /
  Last update: 2009-08-27 17:33    [W:0.040 / U:2.740 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site