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: Sat, 28 May 2011 14:24:55 +0200 Organization: A noiseless patient Spider Lines: 26 Message-ID: <4DE0E997.42657B4A@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> <4DDFAEC8.531D6882@web.de> <2f847af0-7f62-43d2-aff3-f35f0d42c3ce@l2g2000prg.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="14351"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19eQdA6sf3k/ef7yD5VPhW6TQmbisRHWtM=" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en Cancel-Lock: sha1:UdqI0Plrh1uLZuoq36CUj+BmSHY= Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:202 David Schwartz wrote: > > On May 27, 7:01 am, Alexander Terekhov wrote: > > > Simply put, signalling before unlock prolongs the duration of mutex lock > > time (signalling operation takes some time) and that is not good. > > That's true, but there are many factors weighing the other way. The > biggest one is that unlocking the mutex may wake up a thread that > consumes the predicate, leading the subsequent signal to cause a Without wait-morphing, condvar signalling with mutex locked may cause a thread blocked on a condvar to wake up just to be blocked again now on mutex (after wake up due to condvar signalling). > spurious wakeup and two extra context switches. Context switching is old thinking. Nowadays think of idle multi(-core) processors hardware consuming electricity for no good reason instead of context switching: assume that all threads can run in parallel (simultaneously) and that unblocking blocked threads can never impact performance negatively. regards, alexander.