Date: Wed, 10 Jul 2002 12:03:44 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Archie Cobbs <archie@dellroad.org> Cc: John Baldwin <jhb@FreeBSD.org>, freebsd-current@FreeBSD.org, David Xu <davidx@viasoft.com.cn> Subject: Re: Timeout and SMP race Message-ID: <Pine.BSF.4.21.0207101201470.41638-100000@InterJet.elischer.org> In-Reply-To: <200207101616.g6AGG4T28124@arch20m.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 10 Jul 2002, Archie Cobbs wrote: > John Baldwin writes: > > It is the same problem. What we do is change callout_stop() to let you know if > > it actually stopped the timeout or not. You then have to use your own locking > > and synchronization in the timeout function and yourself to close the rest of > > the race. > > OK, thanks. > > What do you think of the idea of letting the timer code (optionally) > handle all the locking and race conditions? > > Even with callout_stop() returning 1 or 0, there still is *lots* > of complexity required on the client side, especially when the > object associated with the timer can be freed after stopping the > timer, and you can have the same timer stopped and then restarted > (which means that if you can't reliably stop the timer before > starting another one, you can get an early timeout due to a previously > not-stopped timer (which you have to check for (which is not trivial))). > > I beg you to look at netgraph/ng_pptpgre.c for an example of the > gymnastics required. For example, you can't just use the object (in > this case a netgraph node) as the void * argument to the timeout > routine: you have to malloc() a separate structure containing just > a pointer to the object, and then in the object itself have a pointer > back to the malloc()'d structure. This is necessary so you can > differentiate a "real" timer timeout from the previously stopped (but > not really stopped) timer timeout if the timer was then restarted. > > In my experience, if the timer routines handle the locking life gets > MUCH simpler for everyone else. I certainly agree that mayb ewe should look at supplying support in teh timeout code for handling this race.. I've had my mind bent by it a few too many times, and I'm starting to think "There's got to be a better way" Archie.. can you pu tup a strawman proposal for the API chenge needed? > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0207101201470.41638-100000>