<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Yeah, the reason I got away w/ it is because the higher level logic
    of my code guaranteed that the correct behavior would happen in
    spite of spurious wakeups except under the most extremely rare of
    conditions.<br>
    <br>
    On 8/31/2010 7:38 PM, Sean Kelly wrote:
    <blockquote
      cite="mid:50B1D486-F12B-46A8-9C2F-4E27BD7F4FAD@invisibleduck.org"
      type="cite">
      <div>
        <div>On Aug 31, 2010, at 4:24 PM, Brad Roberts wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <div>On Tue, 31 Aug 2010, Sean Kelly wrote:<font
              class="Apple-style-span" color="#540000"><font
                class="Apple-style-span" color="#144fae"><br>
              </font></font>
            <blockquote type="cite"><br>
            </blockquote>
            <blockquote type="cite">Theoretical mumbo-jumbo, mostly.
              &nbsp;Here's the wiki entry: <a moz-do-not-send="true"
                href="http://en.wikipedia.org/wiki/Spurious_wakeup">http://en.wikipedia.org/wiki/Spurious_wakeup</a>
              &nbsp;For the most part, it's just good programming practice to
              double-check the invariant on wakeup.<br>
            </blockquote>
            <br>
            Very much not theoretical. &nbsp;I've seen it happen more than a
            little. &nbsp;A lot <br>
            of it can be blamed on using notify all rather than notify
            one type <br>
            behavior. &nbsp;The other ways it can happen is signals for
            things like gc <br>
            pause/resume, or pipe, or ... breaking in-progress sleeps.<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        Oops, for some reason I thought pthread_cont_wait would return
        EINTR for most of those cases, but that's semaphore_wait.
        &nbsp;You're right, a signal, etc, could cause the condition wait
        call to return and we can't detect this inside the Condition
        object. &nbsp;I've seen the signals used for gc cycles cause all
        sorts of blocking calls to return in D, so that's a very real
        issue regardless how good one might consider the rest of the
        logic in their code. &nbsp;For conditions, using a loop is so
        automatic that I've never seen the issue there. &nbsp;Interesting
        that the quotes from D. Butenhof would be so off-base. &nbsp;I guess
        he was simply talking about the wait algorithm itself rather
        than the interaction of conditions with other stuff.</div>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
phobos mailing list
<a class="moz-txt-link-abbreviated" href="mailto:phobos@puremagic.com">phobos@puremagic.com</a>
<a class="moz-txt-link-freetext" href="http://lists.puremagic.com/mailman/listinfo/phobos">http://lists.puremagic.com/mailman/listinfo/phobos</a></pre>
    </blockquote>
    <br>
  </body>
</html>