Groups > comp.programming.threads > #197

Re: cond signal wait

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 <terekhov@web.de>
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> (permalink)
References	<bff468ff-45d7-4e18-8ff5-95238eb94585@c1g2000yqe.googlegroups.com> <87aaebte7o.fsf@justsoftwaresolutions.co.uk> <98cd47de-73d9-48e9-ac18-cc01cac1bb48@z7g2000prh.googlegroups.com> <87lixubzfu.fsf@justsoftwaresolutions.co.uk> <a05141df-cede-4929-9e8d-4b9394fd6858@22g2000prx.googlegroups.com> <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

Show key headers only | View raw

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.

Thread

cond signal wait p6 c6d6 <p6c6d6@gmail.com> - 2011-05-24 18:56 -0700
  Re: cond signal wait Anthony Williams <anthony.ajw@gmail.com> - 2011-05-25 08:46 +0100
    Re: cond signal wait p6 c6d6 <p6c6d6@gmail.com> - 2011-05-25 05:44 -0700
      Re: cond signal wait Anthony Williams <anthony.ajw@gmail.com> - 2011-05-25 15:57 +0100
        Re: cond signal wait p6 c6d6 <p6c6d6@gmail.com> - 2011-05-25 08:34 -0700
          Re: cond signal wait Anthony Williams <anthony.ajw@gmail.com> - 2011-05-25 16:53 +0100
            Re: cond signal wait Alexander Terekhov <terekhov@web.de> - 2011-05-25 19:16 +0200
          Re: cond signal wait David Schwartz <davids@webmaster.com> - 2011-05-26 09:51 -0700
          Re: cond signal wait Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-26 14:48 -0700
            Re: cond signal wait David Schwartz <davids@webmaster.com> - 2011-05-26 23:20 -0700
              Re: cond signal wait Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-27 14:50 -0700
                Re: cond signal wait David Schwartz <davids@webmaster.com> - 2011-05-27 15:15 -0700
                Re: cond signal wait Alexander Terekhov <terekhov@web.de> - 2011-05-28 15:48 +0200
            Re: cond signal wait Alexander Terekhov <terekhov@web.de> - 2011-05-27 16:01 +0200
              Re: cond signal wait David Schwartz <davids@webmaster.com> - 2011-05-27 12:34 -0700
                Re: cond signal wait Alexander Terekhov <terekhov@web.de> - 2011-05-28 14:24 +0200
                Re: cond signal wait David Schwartz <davids@webmaster.com> - 2011-05-29 01:33 -0700
                Re: cond signal wait Alexander Terekhov <terekhov@web.de> - 2011-05-31 15:32 +0200
                Re: cond signal wait David Schwartz <davids@webmaster.com> - 2011-05-31 14:07 -0700

csiph-web