From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Ljj0A-0008VV-C1
	for qemu-devel@nongnu.org; Tue, 17 Mar 2009 19:47:18 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Ljj06-0008VH-0P
	for qemu-devel@nongnu.org; Tue, 17 Mar 2009 19:47:17 -0400
Received: from [199.232.76.173] (port=41786 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Ljj05-0008VE-S0
	for qemu-devel@nongnu.org; Tue, 17 Mar 2009 19:47:13 -0400
Received: from mx2.redhat.com ([66.187.237.31]:51213)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <mtosatti@redhat.com>) id 1Ljj05-0007TD-BA
	for qemu-devel@nongnu.org; Tue, 17 Mar 2009 19:47:13 -0400
Date: Tue, 17 Mar 2009 20:43:44 -0300
From: Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [Qemu-devel] [patch 1/2] qemu: sem/thread helpers
Message-ID: <20090317234344.GA14571@amt.cnet>
References: <20090311161645.344003675@localhost.localdomain>
	<49BD0D98.8050803@redhat.com> <20090317174217.GA10492@amt.cnet>
	<200903172307.08253.paul@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200903172307.08253.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org

On Tue, Mar 17, 2009 at 11:07:07PM +0000, Paul Brook wrote:
> On Tuesday 17 March 2009, Marcelo Tosatti wrote:
> > On Sun, Mar 15, 2009 at 04:15:52PM +0200, Avi Kivity wrote:
> > > Marcelo Tosatti wrote:
> > >> +
> > >> +struct QemuSem {
> > >> +    sem_t sema;
> > >> +};
> > >
> > > Why aren't you using pthread_mutex_t?
> >
> > Because we want the thread waiting on the lock to be awakened
> > once the holder releases it. This does not happen with pthread
> > mutexes AFAIK.
> 
> Really? I'd be surprised if there's any difference. The whole point of a mutex 
> is that it blocks until the other thread releases it.  At best it sounds like 
> you're making fairly sketchy assumptions about the host OS scheduler 
> heuristics.

Actually scratch that. Of course mutex_unlock wakes up waiters. Will
send a better patch soon.