From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Thu, 23 Aug 2012 12:47:10 EDT." References: Date: Thu, 23 Aug 2012 10:53:25 -0700 From: Bakul Shah Message-Id: <20120823175325.EEF27B85B@mail.bitblocks.com> Subject: Re: [9fans] devmnt crash, fix. Topicbox-Message-UUID: af4b2942-ead7-11e9-9d60-3106f5b1d025 On Thu, 23 Aug 2012 12:47:10 EDT Charles Forsyth wrote: > No. It's not true that all sleeps might return spuriously (it might have > been true in Unix, I can't remember). > It's not true in Plan 9. It is not that sleep might return spuriously (that is, the wakeup condition is still false) but that it may have *become* false once again due to an action by another process before the sleeper has had a chance to run. To handle this one would use a pattern like this while (!wakeup_condition(&foo)) sleep(&foo); I haven't looked at this in ages but this used to be the case in unix. So here awakening everyone *spuriously* is /safe/ (but not efficient). doc/sleep.ps says We assume that a particular call to sleep corresponds to a particular call to wakeup, that is, at most one process is asleep waiting for a particular event. But it is not clear to me that another process can't get in to change the condition between the time wakeup() is called and the sleeper actually runs -- the above condition is not violated as the new process won't be sleeping. But if yet another process tries to access the same condition, it will be blocked on getting the rendezvous structure lock?