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).