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

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2012-04-05 09:51, Paolo Bonzini wrote:
> Il 04/04/2012 19:19, Jan Kiszka ha scritto:
>>>>>>>> Yep, this screams for something like QemuEvent which pleases all users
>>>>>>>> of current qemu_eventfd and EventNotifier - and fit into the existing
>>>>>>>> threading/synchronization abstraction layout.
>>>>>>
>>>>>> Kind of, on Unix you cannot poll synchronization primitives so
>>
>> Ah, you meant on Win32 you cannot poll!
> 
> No, I meant poll(2), or select if you prefer. :)
> 
> The difference between EventNotifier and Qemu{Cond,Mutex} is that the
> former can be used in the main loop, the latter cannot.

The latter has no real use case for selection/polling, at least not in
QEMU so far. So that is not the issue here.

What was rather unhandy in the abstraction and build process are the
differences in registering an event with a poll loop.

> 
> Under POSIX you have file descriptors and synchronization primitives.
> You can poll a set of fds, but synchronization primitives are distinct
> and have separate APIs.
> 
> Under Windows you have various kinds of waitable objects.  You can poll
> a set of them with WaitForMultipleObjects, and synchronization
> primitives are waitable objects.  So they have no userspace-only fast
> path and are much more heavyweight than POSIX, but you can poll on
> different synchronization primitives at the same time.  For example you
> can say "I want to get this mutex, but I also need to know if I have to
> do this high-priority task; if so I won't care about getting the mutex
> anymore".
> 
> Now, Qemu{Cond,Mutex} are POSIX-y (lightweight) synchronization
> primitives, EventNotifier (waitable) is a Windows-y synchronization
> primitive.  That's why I think it is substantially different from other
> primitives in qemu-thread.{h,c}.
> 
> (Of course, theis is not entirely accurate.  Windows has always had a
> POSIX-like lightweight mutex, called CRITICAL_SECTION, and we use it for
> QemuMutex; starting from Vista it also grew POSIX-like lightweight
> condvars and rwlocks, but QEMU Win32 code targets XP.  And eventfd could
> be used to implement most Windows synchronization primitives on Linux,
> possibly using EFD_SEMAPHORE).
> 
> BTW you _could_ have a QemuEvent primitive based on Windows manual-reset
> events. It can be used in some cases as a replacement for condvars,
> especially when you have multiple producers and a single consumer (MPSC
> queue is perhaps the easiest lock-free data structure).  It can be made
> very lightweight on Linux using futexes, and would also support timed
> wait easily on Windows.  The API would be more or less like this:
> 
>   void qemu_event_init(QemuEvent *event, bool set);
>   void qemu_event_wait(QemuEvent *event);
>   void qemu_event_timedwait(QemuEvent *event, int ms);
>   void qemu_event_set(QemuEvent *event);
>   void qemu_event_reset(QemuEvent *event);

Yes, qemu_event_wait/timedwait could be added on top later on when we
have a use case in sight. But mapping futexes wouldn't be compatible
with eventfd/pipe based signaling.

> 
> BTW^2 what's the guide for calling something qemu_blah?  So far my idea
> was that qemu_blah should satisfy one of the following conditions:
> 
> 1) it is a wrapper around a system call or ANSI C standard function;
> 
> 2) it handles portability with a trivial implementation for POSIX (resp.
> Win32) and a complex implementation on Win32 (resp. POSIX);
> 
> 3) it modifies global state.
> 
> There are some exceptions (e.g. QemuOpts) but overall it roughly matches
> cases when new qemu_* are being added.

It's hard to solve this in a "trivial" way for both of our platform, but
QemuEvent is a QEMU-styled thread synchronization mechanism, so I think
it deserve to enter the namespace.

> 
> Does it make sense?
> 
> Paolo

Let's see :). I'll post my proposal soon.

Jan

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