[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH 4/7] Get rid of QemuMutex and teach its callers
From: |
Jan Kiszka |
Subject: |
[Qemu-devel] Re: [PATCH 4/7] Get rid of QemuMutex and teach its callers about GStaticMutex |
Date: |
Mon, 24 Jan 2011 23:24:40 +0100 |
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 2011-01-24 22:00, Anthony Liguori wrote:
> Signed-off-by: Anthony Liguori <address@hidden>
>
> diff --git a/cpus.c b/cpus.c
> index 9cf7e6e..0f8e33b 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -321,8 +321,8 @@ void vm_stop(int reason)
>
> #include "qemu-thread.h"
>
> -QemuMutex qemu_global_mutex;
> -static QemuMutex qemu_fair_mutex;
> +GStaticMutex qemu_global_mutex;
> +static GStaticMutex qemu_fair_mutex;
>
> static QemuThread io_thread;
>
> @@ -416,9 +416,9 @@ int qemu_init_main_loop(void)
> qemu_cond_init(&qemu_system_cond);
> qemu_cond_init(&qemu_pause_cond);
> qemu_cond_init(&qemu_work_cond);
> - qemu_mutex_init(&qemu_fair_mutex);
> - qemu_mutex_init(&qemu_global_mutex);
> - qemu_mutex_lock(&qemu_global_mutex);
> + g_static_mutex_init(&qemu_fair_mutex);
> + g_static_mutex_init(&qemu_global_mutex);
> + g_static_mutex_lock(&qemu_global_mutex);
>
Just replacing our own abstraction with glib's looks like a step in the
wrong direction. From a first glance at that library and its semantics
it has at least two major drawbacks:
- Error handling of things like g_mutex_lock or g_cond_wait is, well,
very "simplistic". Once we start to use more sophisticated locking,
more bugs will occur here, and we will need more support than glib is
able to provide (or can you control error handling elsewhere?).
- GMutex is not powerful enough for optional things like PI mutexes -
which is required once we want to schedule parts of qemu with RT
priorities (I did it, it works surprisingly well).
The same concerns apply to other abstractions glib provides for
threading and synchronization. One may work around them, but that will
break abstractions again.
Glib seems to fit standard use case quite comfortably but fails in more
advanced scenarios qemu is already useable for (just lacking a few
additional lines of code).
In short: we need full POSIX where available.
Jan
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-devel] [PATCH 1/2] vl.c: set NULL upon deleting handlers in qemu_set_fd_handler2(), (continued)
[Qemu-devel] [PATCH 3/7] Add support for glib based threading and convert qemu thread to use it, Anthony Liguori, 2011/01/24
[Qemu-devel] [PATCH 7/7] Rename QemuThread to QemuSThread to indicate that it is not a generic thread, Anthony Liguori, 2011/01/24
[Qemu-devel] [PATCH 6/7] Teach vnc server to use GThread directly, Anthony Liguori, 2011/01/24
[Qemu-devel] [PATCH 4/7] Get rid of QemuMutex and teach its callers about GStaticMutex, Anthony Liguori, 2011/01/24
- [Qemu-devel] Re: [PATCH 4/7] Get rid of QemuMutex and teach its callers about GStaticMutex,
Jan Kiszka <=
[Qemu-devel] [PATCH 1/7] io-thread: make sure to initialize qemu_work_cond and qemu_cpu_cond, Anthony Liguori, 2011/01/24
[Qemu-devel] [PATCH 5/7] threads: get rid of QemuCond and teach callers about GCond, Anthony Liguori, 2011/01/24
[Qemu-devel] Re: [RFC 0/7] Introduce hard dependency on glib, Paolo Bonzini, 2011/01/24
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib, Anthony Liguori, 2011/01/24