Date: Thu, 11 Jul 2002 21:37:20 -0600 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: Bruce Evans <bde@zeta.org.au>, bsddiy@yahoo.com, current@FreeBSD.ORG Subject: Re: Timeout and SMP race Message-ID: <200207120337.g6C3bKbA002490@aslan.scsiguy.com> In-Reply-To: Your message of "Thu, 04 Jul 2002 11:53:26 CDT." <20020704115326.R1020@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>I believe I had this conversation with Justin Gibbs earlier; he told >me that the callout consumers (network, cam) had to be aware of the >race and handle this if it matters. I don't particularly like complicating >the callout handlers as illustrated above, though, so if a better scheme >is possible, that would be nice. If callout_stop() is always called from a context that can block and we desire the semantics that upon return from callout_stop(), you are not in the callout handler, it seems that this should be quite easy to achieve. Just track the state of the callout from "commit" and "return", via some flags locked by a global mutex. If a callout_stop is called between "commit" and "return" (just look at a global indicating the currently running callout protected by this mutex), put the thread on a list to be woken by the thread issuing the callout. To handle the case of a reschedule performed by the callout itself, the woken up caller to callout_stop() will have to loop through the test again. In all cases, the global mutex is only held for very short operations as a leaf mutex. >tsleep() is only called from process context With interrupt threads, isn't "process context" a bit of a misnomer? Would it be acceptable for the "interrupt threads" that perform callout_stops to block waiting for them to take effect? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207120337.g6C3bKbA002490>