[Top][All Lists]
[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: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API |
Date: |
Thu, 05 Apr 2012 13:18:53 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
On 2012-04-05 13:07, Paolo Bonzini wrote:
> 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.
Sorry, but that makes no sense to me. It is an abstraction we defined
for QEMU usage in a way that fits precisely our (current) needs. That's
what we did with tons of other abstractions before, so it fits very well
here IMHO.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
- Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API, (continued)
- Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API, Jan Kiszka, 2012/04/04
- Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API, Paolo Bonzini, 2012/04/04
- Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API, Jan Kiszka, 2012/04/04
- Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API, Jan Kiszka, 2012/04/04
- Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API, Paolo Bonzini, 2012/04/05
- Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API, Jan Kiszka, 2012/04/05
- Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API, Paolo Bonzini, 2012/04/05
- Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API,
Jan Kiszka <=
- Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API, Paolo Bonzini, 2012/04/05
- Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API, Jan Kiszka, 2012/04/05
- Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API, Paolo Bonzini, 2012/04/05
- Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API, Jan Kiszka, 2012/04/06
- Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API, Paolo Bonzini, 2012/04/05
- Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API, Jan Kiszka, 2012/04/05
- Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API, Paolo Bonzini, 2012/04/05