From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <11da45046fa8267e7445128ed00724cd@ladd.quanstro.net> References: <11da45046fa8267e7445128ed00724cd@ladd.quanstro.net> Date: Fri, 25 Feb 2011 00:47:56 -0500 Message-ID: Subject: Re: [9fans] sleep/wakeup bug? From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Cc: erik quanstrom Content-Type: text/plain; charset=UTF-8 Topicbox-Message-UUID: b45bf61a-ead6-11e9-9d60-3106f5b1d025 >> assuming a tight 1:1 coupling between sleep and >> wakeup is a recipe for trouble. even if your change >> fixes one possible race (i didn't bother to see what changed), >> you still have to deal with > > the point of sleep/rendezvous is tight coupling, no? no, it's not 1:1. > the change was to move the ready() to after the rendezvous > lock was dropped. therefore the sleeper knows the rendezvous > is not locked by the event that woke him. if one can assert > that each sleep has exactly one wakeup (as is often the case > for rpc-style programming), then that is enough to know > the rendezvous can be retired. that's only true if the sleep sleeps. if sleep checks f(arg) and finds it to be true, then it will not sleep, and the subsequent wakeup will happen after sleep returns (and be a no-op, unless the memory has been freed). > if not a tight coupling, what kind of coupling would you > think is appropriate? when would you think it would be > fair to recycle the rendezvous? 10s? :-) what idiom do > you think would be appropriate for such a case? it is appropriate to reuse the memory when you know that no cpu is still referring to it. you can deal with the main procs. interrupt handlers are the wildcard. put an ilock around the table where the pointer to it is kept, and only use the memory (from an interrupt handler) while inside the ilock. russ