Re: callout handler re-entrancy

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Edgar Fuß <ef%math.uni-bonn.de@localhost> wrote:
> > If not, calls are serialised under kernel lock and it may not necessary 
> > have to be reetrant (terms and conditions apply).
> I'm sorry to say that I know rather little about these T&Cs.
> 
> > Keep in mind that multi-thread safety and reentrancy are not the same.
> I'm afraid I don't get that.
> 
> My application is a scsipi(9) timeout callback. Normally, the same 
> timeout handler is installed for all requests, and, if I'm extremly 
> unlucky, two different requests may time out at the same time.
> So, if someone enters the timeout handler (which is going to reset the 
> hardware and loop through all requests, stopping their callouts and
> asking scsipi to re-schedule the requests), is it safe to assume that the
> timeout handler will not be entered again (on a different CPU, by a
> different thread or whatever) until whoever entered it first returns?
> If that's not safe to assume, what's the suggested way to guard against
> it?

Currently, scsipi(9) is still under the kernel lock, so you do not need
to worry about it.  When this subsytem will be refactored to be MP-safe,
the handler will need to be synchronised using a mutex(9).

-- 
Mindaugas