From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LhRbF-0004ZV-SM for qemu-devel@nongnu.org; Wed, 11 Mar 2009 12:48:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LhRbE-0004ZB-53 for qemu-devel@nongnu.org; Wed, 11 Mar 2009 12:48:08 -0400 Received: from [199.232.76.173] (port=45537 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LhRbE-0004Z8-1m for qemu-devel@nongnu.org; Wed, 11 Mar 2009 12:48:08 -0400 Received: from mx20.gnu.org ([199.232.41.8]:64583) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LhRbD-00073U-Pj for qemu-devel@nongnu.org; Wed, 11 Mar 2009 12:48:07 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LhRbC-000086-LN for qemu-devel@nongnu.org; Wed, 11 Mar 2009 12:48:06 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [patch 1/2] qemu: sem/thread helpers Date: Wed, 11 Mar 2009 16:48:01 +0000 References: <20090311161645.344003675@localhost.localdomain> <20090311161942.482576079@localhost.localdomain> In-Reply-To: <20090311161942.482576079@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903111648.02530.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Anthony Liguori , Marcelo Tosatti > +int qemu_sem_init(QemuSem *sem); > +int qemu_sem_lock(QemuSem *sem); Please don't introduce yet annother set of locking routines. Also, your function names suggest you actually want a mutex, not a semaphore. > +int qemu_sem_lock(QemuSem *sem) > +{ This is bogus. You never check the return value. > +QemuSem qemu_sem; It's entirely unclear what is actually protected by the semaphore. What exactly does the IO thread do? AFAICS device MMIO is still run from within the CPU thread. Device code is not threadsafe (and probably never will be), so you can't run any of the device callbacks in the IO thread either. Doesn't seem like there's a lot left for it to do... Paul