Date: Thu, 1 Apr 2004 16:36:47 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: John Baldwin <jhb@freebsd.org> Cc: Colin Percival <colin.percival@wadham.ox.ac.uk> Subject: Re: locking primatives Message-ID: <20040401162351.C5418@gamplex.bde.org> In-Reply-To: <200403301912.02191.jhb@FreeBSD.org> References: <6.0.1.1.1.20040327201519.044ba550@imap.sfu.ca> <200403301912.02191.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 30 Mar 2004, John Baldwin wrote: > On Saturday 27 March 2004 03:33 pm, Colin Percival wrote: > > I'm trying to implement a callout_stop_safe() function > > (same as callout_stop(), except that it would wait for the > > callout to finish if it is currently in progress) in order > > to get around a rather nasty panic in the kqueue code. All > > I need to do is block until the softclock thread reaches a > > specified point -- this is pretty much the simplest locking > > problem possible. > > Is there any introduction to the various locking methods > > which would give me some indication of which one I should > > use? > > Heh, it's actually not a trivial problem. For one way of dealing with this > race, see the TDF_TIMOFAIL / TDF_TIMEOUT handling stuff in subr_sleepqueue.c. For another way, see the stopping of the "real interval timer" in kern_exit.c and synchronization of this with the callout handler (realitexpire()). All the complications there seemed to be needed, just for one callout. I forget the details. IIRC, the synchronization is very context-dependent (it depends on what realitexpire() does). I think hiding this complexity from individual callouts would require pessimizing callout_*() to keep track of more state. Most callouts don't require any complications, but this may be because too many of them are protected by Giant. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040401162351.C5418>