<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><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. Here's the wiki entry: <a href="http://en.wikipedia.org/wiki/Spurious_wakeup">http://en.wikipedia.org/wiki/Spurious_wakeup</a> For the most part, it's just good programming practice to double-check the invariant on wakeup.<br></blockquote><br>Very much not theoretical. I've seen it happen more than a little. A lot <br>of it can be blamed on using notify all rather than notify one type <br>behavior. 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. You're right, a signal, etc, could cause the condition wait call to return and we can't detect this inside the Condition object. 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. For conditions, using a loop is so automatic that I've never seen the issue there. Interesting that the quotes from D. Butenhof would be so off-base. I guess he was simply talking about the wait algorithm itself rather than the interaction of conditions with other stuff.</div></body></html>