qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API
Date: Thu, 05 Apr 2012 13:07:58 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

Il 05/04/2012 12:55, Jan Kiszka ha scritto:
>> 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.

Note that the thing above would be separate from EventNotifier, which is
why I only mentioned as "by the way".

EventNotifier and anything using eventfd/pipes would _not_ be a
"QEMU-styled thread synchronization mechanism" simply because you can
use it with qemu_aio_set_fd_handler.

That's why I think it should be separate from qemu-threads and stay
outside the QEMU namespace.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]