From owner-freebsd-current Tue Jul 9 21: 0:13 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA1CF37B400; Tue, 9 Jul 2002 21:00:08 -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 17E0C43E3B; Tue, 9 Jul 2002 21:00:08 -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 UAA63867; Tue, 9 Jul 2002 20:35:24 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g6A3Yp323268; Tue, 9 Jul 2002 20:34:51 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200207100334.g6A3Yp323268@arch20m.dellroad.org> Subject: Re: Timeout and SMP race In-Reply-To: "from John Baldwin at Jul 8, 2002 03:27:22 pm" To: John Baldwin Date: Tue, 9 Jul 2002 20:34:51 -0700 (PDT) Cc: David Xu , freebsd-current@FreeBSD.ORG, Julian Elischer 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-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin writes: > > code would be modified to fit this new behaviour, besides this, everywhere > > callout_stop() is used need to hold sched_lock and do a mi_switch() and > > modify td_flags is also unacceptable, this SMP race should be resolved in > > kern_timeout.c. > > How would you resolve it while still preserving the existing semantics? > Saying "this race should be resolved" doesn't explain how you would go about > resolving it. It's a lot harder than it looks. I don't know if this is the same problem or a different problem, but FWIW.. In other multi-threaded applications where a timer library is provided, there's always the race condition between the timer firing in one thread and the timer being stopped in the other thread. The best solution I've come up with is to let the timer registration routine take an optional 'lock *' argument that points to a lock that should be acquired on behalf of the client code before invoking the timeout handler, and released when that handler returns. In addition, the client code acquires this same lock before any calls to timer_start(), timer_stop(), timer_is_running(), etc. Presumably this lock protects whatever object the timer is associated with. This way, the timer is always definitely either running or not. Some minor trickery is necessary in the timer code to avoid lock reversal between the client lock and the timer code's own private lock... but some complexity is unavoidable, and it's simpler and less error-prone to consolidate it all in the timer library. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message