Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API

[Jan Kiszka]

On 2012-04-05 14:48, Paolo Bonzini wrote:
> Il 05/04/2012 14:04, Jan Kiszka ha scritto:
>>> EventNotifier _is not_ yet another thread synchronization primitive.  It
>>> can be used across processes, across the user/kernel boundary, and the
>>> main loop can wait on multiple instances.  QemuThread synchronization
>>> primitives are only usable within a process, cannot be passed to the
>>> kernel, and cannot signal the main loop.
>>
>> Yes, QemuEvent can also be triggered externally - so could at least some
>> of the other synchronization primitives if we had a use case for that.
>>
>>> Besides, QemuEvent is no different from the existing EventNotifier, I
>>> don't think the churn introduced by the rename is justified.
>>
>> It is as EventNotifiers stood aside our synchronization infrastructure,
>> and were only designed around vhost-net. This moves the concept in the
>> center AND applies it broadly, including to the main loop. That "churn"
>> is adoption to our naming and code organization scheme for
>> synchronization primitives.
> 
> 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.

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

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux