From owner-freebsd-arch Wed Jul 10 15:15: 6 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 4A1BA37B400; Wed, 10 Jul 2002 15:15:03 -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 8179A43E3B; Wed, 10 Jul 2002 15:15:02 -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 OAA70143; Wed, 10 Jul 2002 14:59:36 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g6ALx3b29709; Wed, 10 Jul 2002 14:59:03 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200207102159.g6ALx3b29709@arch20m.dellroad.org> Subject: Re: Timeout and SMP race In-Reply-To: "from Julian Elischer at Jul 10, 2002 02:03:47 pm" To: Julian Elischer Date: Wed, 10 Jul 2002 14:59:03 -0700 (PDT) Cc: Archie Cobbs , John Baldwin , davidx@viasoft.com.cn, freebsd-arch@FreeBSD.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 Julian Elischer writes: > > 1. The caller supplies a pointer to the 'handle', which must initially > > be NULL. The handle != NULL if and only if the timer is running. > > The pointer is NULL or the pointee (tm) is NULL? Why would you have to > send a pointer if it must be NULL? SO assuming that the handle is what is > NULL, what IS it when it is not NULL?? An integer? a pointer? a magic > number? I'm assuming it is an 'int' that makes some sense only to the > callout system. The handle is a pointer, but a pointer to something opaque to the caller. All the caller can do with it is see if it's NULL or not. And the non-NULL'ness of the pointer always reflects whether the timer is 'ticking' or not. Secretly we know that the handle points to a 'struct timer_info' which is defined by, and managed in, the timer code. Hence the public header file only contains this: struct timer_info; /* declared but not defined */ typedef struct timer_info *timer_handle_t; > > 2. timer_cancel() guarantees that tfunc() will not be called subsequently > > how? By use of a mutex? If the cancel holds the mutex when the timeout > tries to get it, how do you ensure that the timeout gets scheduled and > notices, before the timeout handle is re-used? You are already holding the mutex when timer_cancel() is called. So the timer can only try to fire afterwards. But timer_cancel() sets a flag in the 'struct timer_info' marking it as invalid so the timeout code knows to just free it. timer_cancel() also sets *handlep (the caller's reference) to NULL before returning but does not necessarily free the 'struct timer_info' right away. Note a 'struct timer_info' is never reused, only the handle gets reused. On the next use, the handle would point to a new 'struct timer_info'. > What if the timeout handle was a structure that included the mutex? You want the mutex that the timer code locks to be the same one that all your other code locks to protect the object. So the caller should tell the timer code which mutex to use, not the other way around. Or maybe I'm misunderstanding your question. -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