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.
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);
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.
Does it make sense?
Paolo
