From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <17cef04d9649c68289bc9e8c70e6ed15@brasstown.quanstro.net> References: <17cef04d9649c68289bc9e8c70e6ed15@brasstown.quanstro.net> Date: Wed, 28 Oct 2009 08:29:09 -0700 Message-ID: Subject: Re: [9fans] double wakeup disallowed From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Topicbox-Message-UUID: 92ca96ce-ead5-11e9-9d60-3106f5b1d025 > i agree that it's wise to check invariants. =C2=A0however > the invarient that there is exactly one wakeup for > every sleep requires some careful accounting that > can be equally error prone. There is no such requirement on callers. > the case i'm worried about is when two or more kprocs > think (perhaps for independent reasons) they need to > wakeup a Rendez. =C2=A0it would seem to me less error prone > (and faster) for wakeup to allow this race and do nothing. It is always legal to call wakeup on a Rendez: Wakeup is called by either a process or an interrupt handler to wake any process sleeping at r, signifying that the corresponding condition is true (the event has occurred). It has no effect if there is no sleeping process. [http://www.vitanuova.com/inferno/man/10/sleep.html] Moving from documentation to code, if two different procs call into /sys/src/9/port/proc.c:/^wakeup on the same r, one will get the lock first. That one will find (p =3D r->p) !=3D nil, ready(p), and set r->p =3D nil.. The next will find (p =3D r->p) =3D=3D ni= l and do nothing. > e.g., the interrupt routines of, e.g. 82563 and igbe take particular > care not to double-interrupt. this requires some extra rts > across the pci/pcie bus. If you are referring to the dance with ctlr->im, I suspect that has much more to do with the peculiarities of the card than the calling convention for wakeup. Russ