Date: Wed, 10 Jul 2002 17:15:52 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Archie Cobbs <archie@dellroad.org> Cc: John Baldwin <jhb@FreeBSD.ORG>, davidx@viasoft.com.cn, freebsd-arch@FreeBSD.ORG, julian@elischer.org Subject: Re: Timeout and SMP race Message-ID: <20020710171552.F65393@prism.flugsvamp.com> In-Reply-To: <200207101815.g6AIFDm28655@arch20m.dellroad.org> References: <XFMail.20020710132809.jhb@FreeBSD.org> <200207101815.g6AIFDm28655@arch20m.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020710171552.F65393>