From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37770 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhWMo-0002oH-FC for qemu-devel@nongnu.org; Mon, 24 Jan 2011 19:02:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PhWMl-00068o-QF for qemu-devel@nongnu.org; Mon, 24 Jan 2011 19:02:38 -0500 Received: from mail-iw0-f173.google.com ([209.85.214.173]:42660) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PhWMl-00068j-Kj for qemu-devel@nongnu.org; Mon, 24 Jan 2011 19:02:35 -0500 Received: by iwn40 with SMTP id 40so4759100iwn.4 for ; Mon, 24 Jan 2011 16:02:34 -0800 (PST) Message-ID: <4D3E130B.3000902@codemonkey.ws> Date: Mon, 24 Jan 2011 18:02:19 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 4/7] Get rid of QemuMutex and teach its callers about GStaticMutex References: <1295902845-29807-1-git-send-email-aliguori@us.ibm.com> <1295902845-29807-5-git-send-email-aliguori@us.ibm.com> <4D3DFC28.4000408@web.de> In-Reply-To: <4D3DFC28.4000408@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org, Paul Brook , Paulo Bonzini , Arun Bharadwaj On 01/24/2011 04:24 PM, Jan Kiszka wrote: > On 2011-01-24 22:00, Anthony Liguori wrote: > >> Signed-off-by: Anthony Liguori >> >> 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 > >