On Sun, Jul 01, 2007 at 06:29:31PM +0100, David Laight wrote:
> On Sun, Jul 01, 2007 at 04:42:53PM +0200, Manuel Bouyer wrote:
> > > 
> > > 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.
> 
> Actually there is a synchronisation issue - it can be very hard for the
> code to DTRT.
> 
> However it would be useful if callout_stop() reported back:
>    1) not running
>    2) cancelled
>    3) couldn't cancel because active.
> 
> (3) is for the case where you don't spin waiting for completion.

For device drivers this would work. In the case of most device drivers,
if the interrupt is fired while the callout is active, the interrupt routine
would spins on the driver's lock until the callout releases it, or the
callout would spin until the interrupt routine releases the driver's lock.

Do we really need a lock in the callout code for callout_stop ?
Wouldn't an atomit test-and-set or an atomic swap be enough (I dind't look
at the code) ?

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