Date: Wed, 10 Jul 2002 17:41:27 -0700 (PDT) From: Archie Cobbs <archie@dellroad.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Archie Cobbs <archie@dellroad.org>, John Baldwin <jhb@FreeBSD.org>, davidx@viasoft.com.cn, freebsd-arch@FreeBSD.org, julian@elischer.org Subject: Re: Timeout and SMP race Message-ID: <200207110041.g6B0fRV30395@arch20m.dellroad.org> In-Reply-To: <3D2CB73E.670D80C8@mindspring.com> "from Terry Lambert at Jul 10, 2002 03:37:50 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > > > You need to add a timer_modify_interval (or something similar), so > > > that intervals can be changed without having to destroy and recreate > > > the timer, though, to avoid another potential race condition. > > > > There's no race condition there. You can just do this to 'reset' a timer: > > > > timer_cancel(&foo->timer); > > timer_start(&foo->timer, ...); > > > > Your timer_modify_interval() would just be an optimization of this. > > > > I forgot to mention that timer_cancel() does nothing if *handlep == NULL. > > This depends on whether you mutex is local to the timer only, or > if it has other uses. Under the model in mind, the mutex would protect the caller's object. > There is also an order of operation race, if you can be preempted > between the cancel and the start. That wouldn't be possible because you've acquired the mutex already. I should have shown that more explicitly: mutex_lock(&foo->mutex); ... /* Reset the timer */ timer_cancel(&foo->timer); /* ok if not running */ timer_start(&foo->timer, ...); ... mutex_unlock(&foo->mutex); Also, the timer library of course will need it's own mutex to protect the timer queues, etc. An invariant is that the timer mutex is always acquired after the caller's mutex to avoid deadlock. This requires minor trickery in the timeout routine. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com 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?200207110041.g6B0fRV30395>