From owner-freebsd-arch Wed Jul 10 18: 0:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F369B37B400; Wed, 10 Jul 2002 18:00:11 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC9E943E4A; Wed, 10 Jul 2002 18:00:10 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id RAA71144; Wed, 10 Jul 2002 17:42:00 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g6B0fRV30395; Wed, 10 Jul 2002 17:41:27 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200207110041.g6B0fRV30395@arch20m.dellroad.org> Subject: Re: Timeout and SMP race In-Reply-To: <3D2CB73E.670D80C8@mindspring.com> "from Terry Lambert at Jul 10, 2002 03:37:50 pm" To: Terry Lambert Date: Wed, 10 Jul 2002 17:41:27 -0700 (PDT) Cc: Archie Cobbs , John Baldwin , davidx@viasoft.com.cn, freebsd-arch@FreeBSD.org, julian@elischer.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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