Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Alexander Terekhov Newsgroups: comp.programming.threads Subject: Re: cond signal wait Date: Fri, 27 May 2011 16:01:44 +0200 Organization: A noiseless patient Spider Lines: 21 Message-ID: <4DDFAEC8.531D6882@web.de> References: <87aaebte7o.fsf@justsoftwaresolutions.co.uk> <98cd47de-73d9-48e9-ac18-cc01cac1bb48@z7g2000prh.googlegroups.com> <87lixubzfu.fsf@justsoftwaresolutions.co.uk> <8ab4e07e-2b9b-4375-b425-dc03e6d017d5@f15g2000pro.googlegroups.com> Reply-To: terekhov@web.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: mx04.eternal-september.org; posting-host="MCbSEzW5qwGLFMNXJh39IQ"; logging-data="11051"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/iSSgD6+UHotFilTZeUR6Do0gkvU8b1wM=" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en Cancel-Lock: sha1:5O7RbalrYTaS9LOX5ywXubvcCIw= Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:197 Joshua Maurice wrote: [...] > Note that actually the idiomatic way is to signal after the critical > section instead of inside it (and definitely not before!!). Signalling > inside the critical section doesn't break correctness, but it may (?) > result in some additional work by the scheduler as it moves a thread > from the cond wait state to the waiting for mutex state, and maybe (?) > some additional context swaps, both of which are bad for performance. Regarding question marks above: Simply put, signalling before unlock prolongs the duration of mutex lock time (signalling operation takes some time) and that is not good. That said, there are cases when condvar signalling must be done with locked mutex (e.g. when condvar may be destroyed by the other thread as the reaction to the predicate change). regards, alexander.