locking primatives

[Bruce Evans]

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