[prev in list] [next in list] [prev in thread] [next in thread]
List: netbsd-tech-kern
Subject: Re: callout handler re-entrancy
From: Mindaugas Rasiukevicius <rmind () netbsd ! org>
Date: 2013-11-25 1:51:13
Message-ID: 20131125015114.42BD714A532 () mail ! netbsd ! org
[Download RAW message or body]
Edgar Fuß <ef@math.uni-bonn.de> 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic