Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #202

Re: cond signal wait

From Alexander Terekhov <terekhov@web.de>
Newsgroups comp.programming.threads
Subject Re: cond signal wait
Date 2011-05-28 14:24 +0200
Organization A noiseless patient Spider
Message-ID <4DE0E997.42657B4A@web.de> (permalink)
References (3 earlier) <87lixubzfu.fsf@justsoftwaresolutions.co.uk> <a05141df-cede-4929-9e8d-4b9394fd6858@22g2000prx.googlegroups.com> <8ab4e07e-2b9b-4375-b425-dc03e6d017d5@f15g2000pro.googlegroups.com> <4DDFAEC8.531D6882@web.de> <2f847af0-7f62-43d2-aff3-f35f0d42c3ce@l2g2000prg.googlegroups.com>

Show all headers | View raw

David Schwartz wrote:
> 
> On May 27, 7:01 am, Alexander Terekhov <terek...@web.de> 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.

Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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