This emulates Win32 manual-reset events using futexes or conditional
variables. Typical ways to use them are with multi-producer,
single-consumer data structures, to test for a complex condition whose
elements come from different threads:
for (;;) {
qemu_event_reset(ev);
... test complex condition ...
if (condition is true) {
break;
}
qemu_event_wait(ev);
}
Or more efficiently (but with some duplication):
... evaluate condition ...
while (!condition) {
qemu_event_reset(ev);
... evaluate condition ...
if (!condition) {
qemu_event_wait(ev);
... evaluate condition ...
}
}
QemuEvent provides a very fast userspace path in the common case when
no other thread is waiting, or the event is not changing state.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Fix following bugs in "fallback implementation of counting semaphores
with mutex+condvar" added in c166cb72f1676855816340666c3b618beef4b976:
- waiting threads are not restarted properly if more than one threads
are waiting unblock signals in qemu_sem_timedwait()
- possible missing pthread_cond_signal(3) calls when waiting threads
are returned by ETIMEDOUT
- fix an uninitialized variable
The problem is analyzed by and fix is provided by Noriyuki Soda.
Also put additional cleanup suggested by Laszlo Ersek:
- make QemuSemaphore.count unsigned (it won't be negative)
- check a return value of in pthread_cond_wait() in qemu_sem_wait()
Signed-off-by: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-id: 1372841894-10634-1-git-send-email-tsutsui@ceres.dti.ne.jp
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Paolo Bonzini