From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:59713)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Sqlts-0004oS-W0
	for qemu-devel@nongnu.org; Mon, 16 Jul 2012 10:03:52 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Sqlti-0004GX-WA
	for qemu-devel@nongnu.org; Mon, 16 Jul 2012 10:03:48 -0400
Received: from mx1.redhat.com ([209.132.183.28]:26330)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Sqlti-0004GO-Nd
	for qemu-devel@nongnu.org; Mon, 16 Jul 2012 10:03:38 -0400
Message-ID: <50041F28.3030203@redhat.com>
Date: Mon, 16 Jul 2012 16:03:20 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1342435377-25897-1-git-send-email-pbonzini@redhat.com>
	<1342435377-25897-8-git-send-email-pbonzini@redhat.com>
	<50040251.5000700@siemens.com> <50041510.5070105@redhat.com>
	<50041869.20006@siemens.com> <500418BC.8080200@redhat.com>
	<50041CE7.80501@siemens.com>
In-Reply-To: <50041CE7.80501@siemens.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 07/12] qemu-thread: add QemuSemaphore
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: "kwolf@redhat.com" <kwolf@redhat.com>, "aliguori@linux.vnet.ibm.com" <aliguori@linux.vnet.ibm.com>, "sw@weilnetz.de" <sw@weilnetz.de>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "stefanha@linux.vnet.ibm.com" <stefanha@linux.vnet.ibm.com>

Il 16/07/2012 15:53, Jan Kiszka ha scritto:
>> > 
>> > qemu_cond_wait only uses WaitForSingleObject with INFINITE timeout, and
>> > the algorithm relies on that.
> I see. But this doesn't look complex awfully. Just move the waker
> signaling from within cond_wait under the mutex as well, maybe add
> another flag if there is really someone waiting, and that's it. The
> costs should be hard to measure, even in line of code.

There is still a race after WaitForSingleObject times out.  You need to
catch the mutex before decreasing the number of waiters, and during that
window somebody can broadcast the condition variable.

I'm not saying it's impossible, just that it's hard and I dislike
qemu_cond_timedwait as much as you dislike semaphores. :)

Paolo