[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [PATCH 4/7] Get rid of QemuMutex and teach its call
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] Re: [PATCH 4/7] Get rid of QemuMutex and teach its callers about GStaticMutex |
Date: |
Tue, 25 Jan 2011 08:39:01 +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-25 01:02, Anthony Liguori wrote:
> On 01/24/2011 04:24 PM, Jan Kiszka wrote:
>> 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).
>>
>
> One of the nice design characteristics of glib/gobject/gtk is that it
> cohabitates well with other APIs.
>
> Nothing stops you from using pthread mutex directly if you really need
> to. It makes you less portable, but sometimes it's a price that has to
> be paid for functionality.
I'm not talking about adding new PI mutexes, I'm talking about
effectively reverting this patch as I need to initializes the existing
ones with PI enabled in the attributes. Or replacing g_mutex_* with
wrappers again to add real error handling. Really, glib is too primitive
here.
Jan
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib, Anthony Liguori, 2011/01/24
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib, Stefan Hajnoczi, 2011/01/25