qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 02/12] qemu-thread: add QemuEvent


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH 02/12] qemu-thread: add QemuEvent
Date: Thu, 16 May 2013 12:15:31 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, May 15, 2013 at 05:48:47PM +0200, Paolo Bonzini wrote:
> 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);
>     }
> 
> Alternatively:
> 
>     ... compute condition ...
>     if (condition) {
>         do {
>             qemu_event_wait(ev);
>             qemu_event_reset(ev);
>             ... compute condition ...
>         } while(condition);
>         qemu_event_set(ev);
>     }
> 
> QemuEvent provides a very fast userspace path in the common case when
> no other thread is waiting, or the event is not changing state.  It
> is used to report RCU quiescent states to the thread calling
> synchronize_rcu (the latter being the single consumer), and to report
> call_rcu invocations to the thread that receives them.

It would be nice to describe the need for the Linux futex code.  pthread
mutex/condvars are implemented in terms of futexes already, so how much
benefit is there - I thought they stay in userspace in the non-contended
case too?

Stefan



reply via email to

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