In the documentation for InterruptAttachEvent( ) it is mentioned that the
InterruptAttachEvent performs a InterruptMask operation. The documentation
further states that we should avoid using InterruptMask and InterruptUnmask
in the case of SMP. And try to use InterruptLock and InterruptUnlock
instead.
Does this mean that InterruptAttachEvent should be avoided under SMP.
In the documentation for InterruptAttachEvent( ) it is mentioned that the
InterruptAttachEvent performs a InterruptMask operation. The documentation
further states that we should avoid using InterruptMask and InterruptUnmask
in the case of SMP. And try to use InterruptLock and InterruptUnlock
instead.
Does this mean that InterruptAttachEvent should be avoided under SMP.
Please say exactly where - I couldn’t find it when I looked in the 6.1
documentation. What I did find (and is correct) is that InterruptEnable()
and InterruptDisable() should be avoided. InterruptMask and InterruptUnmask()
are fine on SMP.
Dennis <> dmoses@z-kat.com> > wrote:
In the documentation for InterruptAttachEvent( ) it is mentioned that
the
InterruptAttachEvent performs a InterruptMask operation. The
documentation
further states that we should avoid using InterruptMask and
InterruptUnmask
in the case of SMP. And try to use InterruptLock and InterruptUnlock
instead.
Does this mean that InterruptAttachEvent should be avoided under SMP.
Please say exactly where - I couldn’t find it when I looked in the 6.1
documentation. What I did find (and is correct) is that InterruptEnable()
and InterruptDisable() should be avoided. InterruptMask and
InterruptUnmask()
are fine on SMP.
I tried out interruptmask and it works just fine. I think i misinterpreted
the documentation.
It does work, in the sense that it masks the interrupt; what the docs
are trying to say is that on a multiprocessor, masking an interrupt
doesn’t reliably prevent the interrupt handler from clobbering your
variables like it does on a single processor. If you call
InterruptMask() just after another processor has received the interrupt,
your handler might run (on the other processor) after InterruptMask()
has returned.
With InterruptAttachEvent(), it’s less of a problem because it’s less
surprising that your event may arrive after you’ve masked the interrupt,
even on a single processor. You simply have no way to tell whether the
interrupt was handled just before or just after you masked it…
With InterruptAttachEvent(), it’s less of a problem because it’s less
surprising that your event may arrive after you’ve masked the interrupt,
even on a single processor. You simply have no way to tell whether the
interrupt was handled just before or just after you masked it…