[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: callout handler re-entrancy
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
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).
Main Index |
Thread Index |