Date: Wed, 10 Jul 2002 14:59:03 -0700 (PDT) From: Archie Cobbs <archie@dellroad.org> To: Julian Elischer <julian@elischer.org> Cc: Archie Cobbs <archie@dellroad.org>, John Baldwin <jhb@FreeBSD.org>, davidx@viasoft.com.cn, freebsd-arch@FreeBSD.org Subject: Re: Timeout and SMP race Message-ID: <200207102159.g6ALx3b29709@arch20m.dellroad.org> In-Reply-To: <Pine.BSF.4.21.0207101348170.41638-100000@InterJet.elischer.org> "from Julian Elischer at Jul 10, 2002 02:03:47 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207102159.g6ALx3b29709>