From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <11da45046fa8267e7445128ed00724cd@ladd.quanstro.net> <24bb48f61c5eab87a133b82a9ef32474@coraid.com> <2808a9fa079bea86380a8d52be67b980@coraid.com> <40925e8f64489665bd5bd6ca743400ea@coraid.com> From: Venkatesh Srinivas Date: Fri, 25 Feb 2011 11:09:03 -0500 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=00248c6a695aa922a2049d1d8d9d Subject: Re: [9fans] sleep/wakeup bug? Topicbox-Message-UUID: b4f16c04-ead6-11e9-9d60-3106f5b1d025 --00248c6a695aa922a2049d1d8d9d Content-Type: text/plain; charset=UTF-8 On Fri, Feb 25, 2011 at 1:51 AM, Russ Cox wrote: > > your layout in your first email (i think) assumes that wakeup > > can be called twice. > > it doesn't. the scenario in my first email has exactly one > sleep and one wakeup. > > the canonical problem you have to avoid when implementing > sleep and wakeup is that the wakeup might happen before > the sleep has gotten around to sleeping. > There is a pattern in DragonFly BSD for use with tsleep (tsleep is evolutionarily related to p9's sleep, though the descent is tortuous), tsleep_interlock. tsleep_interlock(WAITCHAN); /* Kick off some operation or release some higher level lock or w/e */ tsleep(WAITCHAN, ...); tsleep_interlock queues a process but does not actually go to sleep. If a wakeup happens after the tsleep_interlock but before tsleep has fully slept, the process does not sleep in tsleep(). I do not know if a similar design would be feasible given Plan 9's sleep/wakeup; at first glance, it looks to be so - sleep_interlock would look similar to sleep's front-end, but it would not 'gotolabel(&m->sched)'. -- vs --00248c6a695aa922a2049d1d8d9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 25, 2011 at 1:51 AM, Russ Cox <rsc@swtch.com> wrote:
> your layout in your first email (i think) assumes that wakeup
> can be called twice.

it doesn't. =C2=A0the scenario in my first email has exactly one
sleep and one wakeup.

the canonical problem you have to avoid when implementing
sleep and wakeup is that the wakeup might happen before
the sleep has gotten around to sleeping.

There is= a pattern in DragonFly BSD for use with tsleep (tsleep is evolutionarily r= elated to p9's sleep, though the descent is tortuous), tsleep_interlock= .

tsleep_interlock(WAITCHAN);
/* Kick off some operation or release so= me higher level lock or w/e */
tsleep(WAITCHAN, ...);

tsleep_inte= rlock queues a process but does not actually go to sleep. If a wakeup happe= ns after the tsleep_interlock but before tsleep has fully slept, the proces= s does not sleep in tsleep().

I do not know if a similar design would be feasible given Plan 9's = sleep/wakeup; at first glance, it looks to be so - sleep_interlock would lo= ok similar to sleep's front-end, but it would not 'gotolabel(&m= ->sched)'.

-- vs

--00248c6a695aa922a2049d1d8d9d--