Il 05/04/2012 15:00, Jan Kiszka ha scritto:
>> > But QemuEvent takes away the best name for a useful concept (a
>> > cross-platform implementation of Win32 events; you can see that in the
> The concept is not lost, it perfectly fit this incarnation. Just the
> special futex version for Linux is not feasible.
It's not just about the futex version. Can you implement a
userspace-only fast path? Perhaps with EFD_SEMAPHORE you can:
x = state of the event
bit 0 = set/reset
bit 1..31 = waiters
set
y = xchg(&x, 1)
if y > 1
write y >> 1 to eventfd
wait
do {
y = x
if (y & 1) return;
} while (fail to cmpxchg x from y to y + 2)
read from eventfd
reset
cmpxchg x from 1 to 0
but what if you are falling back to pipes?
2) It's much more heavyweight since (like Windows primitives) you need
to set aside OS resources for each QemuEvent. With mutexes and condvars
the kernel-side waitqueues come and go as they are used.
>> > RCU patches which were even posted on the list). We already have a
>> > perfectly good name for EventNotifiers, and there's no reason to break
>> > the history of event-notifier.c.
> Have you measured if the futex optimization is actually worth the
> effort, specifically compared to the fast path of mutex/cond loop?
A futex is 30% faster than the mutex/cond combination. It's called on
fast paths (call_rcu and, depending on how you implement RCU,
rcu_read_unlock) so it's important.
Paolo
