_ISR_Handler

[Allan Hessenflow]

> But I have a suspicion that if you had a context switch
> necessary and an ISR signal to thread, the ISR signal
> to thread would get "stuck high" for a bit too long.
> It would take a subsequent interrupt to clear it when
> it caused a _Thread_Dispatch that it didn't need to.
>
> I am prone to think it would be safer to ALWAYS clear
> it in the generic _Thread_Dispatch and not make the
> individual ports do anything but read it. 
> It is Monday and this is a subtle issue.  I would appreciate
> some feedback.

I'm looking at the m68k code now, and it looks to me like it clears
_ISR_Signals_to_thread_executing if and only if it is going to call
_Thread_Dispatch.  So that should be equivalent to clearing it in
the generic _Thread_Dispatch.  This is different than the pseudo code
in the documentation; that code also clears it if
_Thread_Dispatch_disable_level is non-zero.

As the m68k port is probably well tested I'll do it that way for now,
at least until you've had a chance to think about it to see if it
could be more efficient.


The Blackfin processor doesn't make it easy to do the _Thread_Dispatch
call at the conclusion of an interrupt, and that is complicated by Analog
Device's vague documentation in some areas, and by the fact that their
support people don't seem to have access to anyone who knows how the
design works.  So I completely understand why the existing RTEMS Blackfin
ISR works the way it does, but the system could not be called a preemptive
RTOS as it is because preemption doesn't always work.  I have an ISR that
does seem to work, and if the processor is working in the way I think
it does then preemption is fine.  I just wish Analog Devices would answer
my question about how a part of their processor works so I could know for
sure; it doesn't look like that is going to happen so all I can do is keep
testing.

allan

-- 
Allan N. Hessenflow      allanh at kallisti.com