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

[Anthony Liguori <anthony@codemonkey.ws>]

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.

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

If the problem we have is that we have such advanced use of threading 
and locking in QEMU such that the glib API is not enough and we find 
ourselves constantly calling into the pthread's API directly, then 
that's a wonderful problem to have.

Regards,

Anthony Liguori

> Jan
>
>