From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 15:39:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51486106564A for ; Mon, 28 Feb 2011 15:39:47 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from mx.utwente.nl (mx1.utsp.utwente.nl [130.89.2.12]) by mx1.freebsd.org (Postfix) with ESMTP id C93E28FC15 for ; Mon, 28 Feb 2011 15:39:46 +0000 (UTC) Received: from pieter-dev.localnet (lux.student.utwente.nl [130.89.161.112]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id p1SFdeBh004795; Mon, 28 Feb 2011 16:39:40 +0100 From: Pieter de Goeje To: freebsd-hackers@freebsd.org Date: Mon, 28 Feb 2011 16:39:39 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; ) References: <4D6ABA14.80208@rawbw.com> <201102280309.56631.pieter@degoeje.nl> <4D6BBA70.8010503@rawbw.com> In-Reply-To: <4D6BBA70.8010503@rawbw.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102281639.40151.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Yuri Subject: Re: Is pthread_cond_signal(3) man page correct? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 15:39:47 -0000 On Monday 28 February 2011 16:08:32 Yuri wrote: > On 28.02.11 2:41, Pieter de Goeje wrote: > > pthread_cond_signal() can indeed wake up more than one thread. That's why > > you should always wrap pthread_cond_wait() in a loop. For example a > > blocking > > > queue could be implemented like this (pseudo code): > Thank you. Now its clear that POSIX allows multiple wake ups. > > But my question is: why would the standard define it this way? Why would > it allow essentially arbitrary number of waiting threads to be woken up > by one event? I can't think of any practical app that would need "some > threads to be woken up". It would be natural to expect it to wake > exactly one thread. So the users won't need to have any special cycles > like you suggested in your previous post. > > What is the underlying reason for POSIX to define it this way and for > OSes to implement it this way? Well you need the extra cycles anyway because pthread_cond_wait() can wakeup for no apparent reason. As David Xu explained, in FreeBSD this can for instance happen because a signal is delivered to the process or the process called fork(). For pthread library implementors its probably easier (faster) to guarantee that at least one thread will be woken by pthread_cond_signal() instead of exactly one. Because the application needs to check the condition's predicate anyway it's logical to allow for a more relaxed specification. In that sense, pthread_cond_signal() is only here because it is a lot faster than calling pthread_cond_broadcast() all the time (because of the thundering herd problem). - Pieter