From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQu7B-0002kj-Li for qemu-devel@nongnu.org; Wed, 03 Feb 2016 04:52:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQu78-0005UZ-CY for qemu-devel@nongnu.org; Wed, 03 Feb 2016 04:52:45 -0500 Received: from mail-wm0-x242.google.com ([2a00:1450:400c:c09::242]:32916) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQu77-0005UD-UH for qemu-devel@nongnu.org; Wed, 03 Feb 2016 04:52:42 -0500 Received: by mail-wm0-x242.google.com with SMTP id r129so6532311wmr.0 for ; Wed, 03 Feb 2016 01:52:41 -0800 (PST) Sender: Paolo Bonzini References: <1452870739-28484-1-git-send-email-pbonzini@redhat.com> <1452870739-28484-6-git-send-email-pbonzini@redhat.com> <20160202145206.GB32084@stefanha-x1.localdomain> <56B0C4E3.5060808@redhat.com> <20160203093444.GB26227@stefanha-x1.localdomain> From: Paolo Bonzini Message-ID: <56B1CDE6.9070700@redhat.com> Date: Wed, 3 Feb 2016 10:52:38 +0100 MIME-Version: 1.0 In-Reply-To: <20160203093444.GB26227@stefanha-x1.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 05/16] iothread: release AioContext around aio_poll List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org On 03/02/2016 10:34, Stefan Hajnoczi wrote: >>>>>>>>> + g_usleep(500000); >>>>> Sleep? >>> >>> What about it? :) > Sleep in a loop is inefficient but at least correct. > > A sleep outside a loop is a race condition. If the machine is > heavily loaded, whatever you are waiting for may not happen in 500 > ms and the test case is unreliable. > > What is the purpose of this sleep? In the test the desired ordering of events is main thread additional thread --------------------------------------------------------------------- lock start_lock start thread lock start_lock (waits) acquire context unlock start_lock lock start_lock (returns) unlock start_lock aio_poll poll() <<<< event_notifier_set <<<< Comparing the test to QEMU, the roles of the threads are reversed. The test's "main thread" is QEMU's dataplane thread, and the test's additional thread is QEMU's main thread. The sleep "ensures" that poll() blocks before event_notifier_set. The sleep represents how QEMU's main thread acquires the context rarely, and not right after starting the dataplane thread. Because this is a file descriptor source, there is really no difference between the code's behavior, no matter if aio_poll starts before or after the event_notifier_set. The test passes even if you remove the sleep. Do you have any suggestion? Just add a comment? Paolo