Date: Wed, 10 Jul 2002 09:16:03 -0700 (PDT) From: Archie Cobbs <archie@dellroad.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Archie Cobbs <archie@dellroad.org>, Julian Elischer <julian@elischer.org>, freebsd-current@FreeBSD.org, David Xu <davidx@viasoft.com.cn> Subject: Re: Timeout and SMP race Message-ID: <200207101616.g6AGG4T28124@arch20m.dellroad.org> In-Reply-To: <XFMail.20020710111130.jhb@FreeBSD.org> "from John Baldwin at Jul 10, 2002 11:11:30 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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. -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?200207101616.g6AGG4T28124>