“Evan Hillas” <evanh@clear.net.nz> wrote in message
news:d8ts3s$4tp$1@inn.qnx.com…
Wojtek Lerch wrote:
But the lack of further interrupts is caused by higher-priority threads,
perhaps belonging to some application or a completely unrelated driver,
interferring with the unmasking, isn’t it?
Or are you complaining about some drivers that use IAE() and spend too
much time doing unnecessary things before unmasking the interrupt?
That’s, of course, a different issue, and it’s not really very specific
to IAE() – it doesn’t differ much from having an ISR that spends too
much time doing unnecessary things before returning, except that the ISR
problem may be easier to notice sooner, because it affects all
lower-priority interrupts in addition to its own.
Yes, all of the above issues are what’s wrong with IAE().
How come? The first one is just one of many possible symptoms of setting up
thread priorities incorrectly. The second and third are about badly
designed drivers that are doing unnecessary things before allowing
interrupts to happen again. The third one actually is about an ISR – how
can it be a problem of IAE()?..
To fix it; the replacement of the call to IAE() with an equivalent ISR
that masks the device and sends an event to the waiting handler thread is
all that is needed.
Or leave the IAE() in and make sure that your thread masks the device and
calls InterruptUnmask() as quickly as possible, and that its priority is
high enough. This will mask the interrupt for a bit longer than your fix
does, but yours masks all the lower-priority interrupts for longer, because
the kernel needs to switch the address space and run your ISR before issuing
the EOI. Which way is better depends on what devices, if any, you’re
sharing the interrupt with, and what devices are attached to lower priority
interrupts. And how good you are at picking thread priorities correctly.
A complex driver can spend as much time as it likes processing it’s data
and can be preempted by higher priority and whatever else. That’s the
very reason to pass the hard work off to the thread level. That’s all
fine and dandy. No problems there.
Not exactly: if it’s pre-empted for too long, you’ll still lose incoming
data, or fail to stop the vehicle before it hits the wall, or whatever.
Just because you’re not using IAE() doesn’t mean that you don’t have to
worry about setting up thread priorities correctly; and if you do set up
thread priorities correctly, IAE() is not a problem.
Yes, setting priorities correctly can be more difficult when IAE() or IM()
are involved, and may make it easier for you to shoot yourself in the foot.
But that’s a simple consequence of having more variables to account for, not
a fundamental problem of IAE(). Having more variables to play with can
often be a good thing.
It’s not the duration of a driver’s activity that is the fundamental flaw.
It’s just the IRQ masking, which is completely unneeded in most cases.
No, it’s the combination of both. There’s no way to completely get rid of
masking – you actually want it to happen in the hardware when the
interrupt is received. The problem is the duration of the masking and how
much control you have over it.
.
