From owner-freebsd-arch Wed Jul 10 15:17:31 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 0DDA937B400; Wed, 10 Jul 2002 15:17:27 -0700 (PDT) Received: from prism.flugsvamp.com (66-191-112-47.mad.wi.charter.com [66.191.112.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0B2043E5E; Wed, 10 Jul 2002 15:17:25 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id g6AMFqC26935; Wed, 10 Jul 2002 17:15:52 -0500 (CDT) (envelope-from jlemon) Date: Wed, 10 Jul 2002 17:15:52 -0500 From: Jonathan Lemon To: Archie Cobbs Cc: John Baldwin , davidx@viasoft.com.cn, freebsd-arch@FreeBSD.ORG, julian@elischer.org Subject: Re: Timeout and SMP race Message-ID: <20020710171552.F65393@prism.flugsvamp.com> References: <200207101815.g6AIFDm28655@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200207101815.g6AIFDm28655@arch20m.dellroad.org> 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, Jul 10, 2002 at 11:15:13AM -0700, Archie Cobbs wrote: > > [ NOTE: I'm moving this discussion to freebsd-arch@freebsd.org ] > > John Baldwin writes: > > > What do you think of the idea of letting the timer code (optionally) > > > handle all the locking and race conditions? > > > > I'm not sure it can in a clean fashion since of the few cases I've known > > so far each client needs a customized solution. I am open to ideas though. > > I'm also open to some redesign of how callouts work to begin with (maybe > > using other threads than the one running softclock() to actually execute > > callout handlers, etc.). > > FWIW, here is an API I've used before. This handles all race > conditions and the 'other thread' question. > > struct timer_event; /* opaque structure */ > > typedef struct timer_event *timer_handle_t; /* caller's timer "handle" */ > > typedef void timer_func_t(void *arg); /* timeout function type */ > > /* flags for timer_start() */ > #define TIMER_RECURRING 0x0001 /* timer is recurring */ > #define TIMER_OWN_THREAD 0x0002 /* handle in separate thread */ > > 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. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message