From owner-freebsd-arch Wed Jul 10 18: 0:30 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 A011737B400; Wed, 10 Jul 2002 18:00:23 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E5BA43E58; Wed, 10 Jul 2002 18:00:22 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020711010021.TGOS6023.sccrmhc02.attbi.com@InterJet.elischer.org>; Thu, 11 Jul 2002 01:00:21 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA43259; Wed, 10 Jul 2002 17:53:33 -0700 (PDT) Date: Wed, 10 Jul 2002 17:53:30 -0700 (PDT) From: Julian Elischer To: Archie Cobbs Cc: Jonathan Lemon , John Baldwin , davidx@viasoft.com.cn, freebsd-arch@FreeBSD.ORG Subject: Re: Timeout and SMP race In-Reply-To: <200207110025.g6B0PHA30341@arch20m.dellroad.org> Message-ID: MIME-Version: 1.0 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 On Wed, 10 Jul 2002, Archie Cobbs wrote: > Jonathan Lemon writes: > > > extern int timer_start(timer_handle_t *handlep, mutex_t *mutexp, > > > timer_func_t tfunc, void *arg, u_int delay, > > > int flags); > > > extern void timer_cancel(timer_handle_t *handlep); > > > extern int timer_remaining(timer_handle_t handle, u_int *delayp); > > > > It seems to me that we can achieve the same functionality without > > changing the callout API too much. You mention that the mutex (if supplied) > > will be acquired before calling tfunc. This means that it has to be > > stored somewhere, presumably in the callout structure itself. > > > > The callout() consumers typically allocate their own storage, so perhaps > > we should add an (optional) pointer to a mutex to the callout structure, > > where the mutex is obtained/released before the callout function is made. > > Yep, that would work too.. essentially it's the same thing. > > If you're doing that, why not just store the mutex itself in the > callout structure, rather than a pointer to it? I guess if you did > that then you would then need some kind of flag that says whether > to use it or not. Or.. maybe there would be some way for the timer > code to tell if the mutex has been initialized or not, and use this > to decide whether to use it or not? Some timeouts don't need cancelability. (we'll not go here into whether having a separate timeout for each TCP session was a good or bad thing) In that case they shouldn't have to pay the price of carrying around a mutex.. unless we can say that there are almost no such cases.. On the other hand how many timeouts canyou do at one time? I'd say N where N is the number of processors. what is the hit from having just ONE (1) mutex. to cover all timeout operations. Surely all we need is for a certain amount of atomicity.. You do not want more than one processor at a time doing timeouts, so if you play your cards right, the same mutex could be used to make sure that removals didn;t clash with executions. > > -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