From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGT0K-0005us-EE for qemu-devel@nongnu.org; Thu, 20 Feb 2014 07:45:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WGT0B-0008Tg-MZ for qemu-devel@nongnu.org; Thu, 20 Feb 2014 07:45:28 -0500 Received: from mail-wg0-x235.google.com ([2a00:1450:400c:c00::235]:35943) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGT0B-0008TT-Fp for qemu-devel@nongnu.org; Thu, 20 Feb 2014 07:45:19 -0500 Received: by mail-wg0-f53.google.com with SMTP id x12so1438261wgg.32 for ; Thu, 20 Feb 2014 04:45:18 -0800 (PST) Date: Thu, 20 Feb 2014 13:45:13 +0100 From: Stefan Hajnoczi Message-ID: <20140220124513.GA15847@stefanha-thinkpad.redhat.com> References: <1389318316-18841-1-git-send-email-stefanha@redhat.com> <1389318316-18841-2-git-send-email-stefanha@redhat.com> <20140120102228.GA5727@T430.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140120102228.GA5727@T430.nay.redhat.com> Subject: Re: [Qemu-devel] [RFC v2 1/6] rfifolock: add recursive FIFO lock List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: Kevin Wolf , Michael Roth , qemu-devel@nongnu.org, Stefan Hajnoczi , Igor Mammedov , Paolo Bonzini On Mon, Jan 20, 2014 at 06:22:28PM +0800, Fam Zheng wrote: > On Fri, 01/10 09:45, Stefan Hajnoczi wrote: > > QemuMutex does not guarantee fairness and cannot be acquired > > recursively: > > > > Fairness means each locker gets a turn and the scheduler cannot cause > > starvation. > > > > Recursive locking is useful for composition, it allows a sequence of > > locking operations to be invoked atomically by acquiring the lock around > > them. > > > > This patch adds RFifoLock, a recursive lock that guarantees FIFO order. > > Its first user is added in the next patch. > > > > RFifoLock has one additional feature: it can be initialized with an > > optional contention callback. The callback is invoked whenever a thread > > must wait for the lock. For example, it can be used to poke the current > > owner so that they release the lock soon. > > > > Is it better to make the contention callback per-caller than per-lock? > Considering that different caller may want to do different things depending on > current code path. Perhaps it will make sense to change it in the future. For now it means callers use the standard lock/unlock function. They don't have to know what actions are needed to poke the current lock-holder.