On Wednesday,  5 September 2001 at 20:28:57 -0700, Matt Jacob wrote:
> On Wed, 5 Sep 2001, Jason R Thorpe wrote:
>> On Thu, Sep 06, 2001 at 12:14:19PM +0930, Greg Lehey wrote:
>>
>>> All else being equal, given the choice between a variable or a
>>> function, I'd use the variable any day.
>>
>> I'd rather restructure the entire code path so the test is
>> never necessary :-)
>
> Then we need to implement ithreads as Solaris implements them- so you *can*
> call tsleep from hardware interrupt level

That would definitely be overkill for this purpose.

> and as FreeBSD supposedly gropes toward.

Well, "supposedly" is wrong there, unless you mean the question of
whether FreeBSD is intentionally imitating Sun.  I did the initial
implementation of the threads long before I knew that Sun had
something similar.  The real issue is whether the interrupt threads
will be as useful as they promise to be.

> I'm pretty convinced that lacking such freedom, knowing whether it
> is safe to call tsleep is functionality worth having. The
> implementation need not be hacky, and could, in fact, be SMP
> aware. After all, it's per processor data (in some systems, at
> least) as to whether you're running a context where it is safe to
> sleep && be (re)schedulable. Despite what Bill says, it need not be
> a costly test- but this is why I asked whether it would be
> invasive. The answer I get is "Yes" and the implied (from Jason)
> "You need to rewrite your driver"- which is somewhat annoying.

I'm neutral on this one.  Basically, it's a single instruction in the
interrupt stub (increment interrupt nesting level) and another in the
return (decrement), so it's not much overhead.  But it would probably
result in a cache miss on entry, probably not on exit, and that's
equivalent to about 100 instructions.

> Frankly, the alternative is a less functional system. But you know-
> I *really* don't need to argue this at all. I think it would be
> useful. If others don't see that- that's fine too.

The real issue is whether it's always possible to find an alternative.
In this case, one such might be to set your own variable when entering
your interrupt routines, and resetting it on leaving them.

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers