Date: Mon, 28 Feb 2011 07:08:32 -0800 From: Yuri <yuri@rawbw.com> To: freebsd-hackers@freebsd.org Cc: Pieter de Goeje <pieter@degoeje.nl> Subject: Re: Is pthread_cond_signal(3) man page correct? Message-ID: <4D6BBA70.8010503@rawbw.com> In-Reply-To: <201102280309.56631.pieter@degoeje.nl> References: <4D6ABA14.80208@rawbw.com> <4D6AC17A.7020505@rawbw.com> <201102280309.56631.pieter@degoeje.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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? Yuri
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D6BBA70.8010503>