Re: [Qemu-devel] Re: [PATCH 4/7] Get rid of QemuMutex and teach its callers about GStaticMutex

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2414 bytes --]

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<aliguori@us.ibm.com>
>>>
>>> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]