Date: Fri, 28 Apr 2000 14:34:00 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: "Justin T. Gibbs" <gibbs@freebsd.org> Cc: Archie Cobbs <archie@whistle.com>, freebsd-arch@freebsd.org Subject: Re: timeout(9) question Message-ID: <20000428143400.C84498@prism.flugsvamp.com> In-Reply-To: <200004281903.NAA03592@caspian.plutotech.com> References: <200004281714.KAA73019@bubba.whistle.com> <200004281903.NAA03592@caspian.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 28, 2000 at 01:03:00PM -0600, Justin T. Gibbs wrote:
> >The way it works now, it seems like there's an unavoidable race
> >condition.
>
> It is avoidable, if necessary, by adding and maintaining additional
> state.
>
> Software interrupts are serialized. This implies that no other software
> interrupt (including the network software interrupt that is blocked by
> splnet()) can pre-empt you during the execution of your handler.
> Naturally, this does not prevent hardware interrupts from getting in there.
>
> >Another thing that bugs me is there's not an easy way to check if
> >a timeout is already registered, eg:
> >
> > extern int timeout_registered(struct callout handle);
>
> Use the callout interface instead of timeout. timeout(9) should
> be deprecated anyway. Perhaps Garret will write up a new man
> page for the callout interface since he added it, but until then,
> take a look at sys/callout.h.
Or take a look at how the races are handled in netint/tcp_timer.c:
s = splnet();
if (callout_pending(tp->tt_keep)) {
splx(s);
return;
}
callout_deactivate(tp->tt_keep);
where a network interrupt could come and and reset the timer between
when it was taken off the timing wheel, and the timeout servicing
routine was actually called.
--
Jonathan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000428143400.C84498>