On Sun, Jul 01, 2007 at 03:05:35PM +0100, Andrew Doran wrote:
> On Mon, Jun 25, 2007 at 08:03:52PM +0200, Manuel Bouyer wrote:
> 
> > On Mon, Jun 25, 2007 at 01:55:43PM +0100, Andrew Doran wrote:
> > > > Do you have a way to do this easily ? A lot of drivers do schedule or
> > > > stop callouts from their interrupt function.
> > > 
> > > Thinking about it further, maybe the only function that needs to do the
> > > blocking synchronization (wait for the callout to complete) is callout_stop
> > > itself. In that case, if a driver really needs to ensure that callouts occur
> > > in a rigid order, then it would need to use a thread to call callout_stop
> > > before the other operations, like callout_reset. Do you think that would
> > > work?
> > 
> > Would it still be possible to call callout_stop() from interrupt context
> > if we don't care waiting for the call to complete ? For most cases in drivers
> > the callout is scheduled for several seconds (at minimum) in the future while
> > the interrupt will happen within milliseconds, so in the common case
> > the callout will be armed for a very short period. 
> 
> After some thought the best suggestion I have is to synchronize only if the
> callout is marked with the CALLOUT_MPSAFE flag. If the code is MT safe, then
> someone has gone over it and thought about the synchronization issues
> involved. And I think that synchronization really only needs to happen for
> callout_stop().

I think there is a good number of case where we don't want synchronisation
in callout_stop() at all (either because the caller has its own
synchronisarion, or because it doesn't care) and I think it's ortogonal to
CALLOUT_MPSAFE.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--