Re: [ECOS] Re: On ecos interrupt process

[Nick Garnett <nickg at ecoscentric dot com>]

Brij Bihari Pandey <fuzzhead012@yahoo.com> writes:

> We will reach this point only via unlock_inner(0) call.  Now I am
> bit confused here, seems like I am missing something in
> understanding things.
> 
> The schedlock won't be zeroed out till the "switched out" thread is
> "switched in" again and we return back into same place in execution
> here. That means that DSR processing can remain pending for a long
> time!!!!

Well, the switched in thread will switch in to the same point in its
call graph, and will usually zero the lock itself.  Context switching
always occurs between threads that have non-zero scheduler locks. The
exit sequence of unlock_inner() either zeros the lock or set it to the
thread's current value.

> 
> As per unlock_inner code, zero_sched_lock will be called only if
> new_lock was zero in current invocation of unlock_inner(new_lock),
> and the next switched-in thread, might not have new_lock value as
> zero, in it's context (it might have been taken off last time
> because of reschedule call).

The routines that call reschedule() usually call unlock() just a few
lines of code later. They do it to avoid race conditions. Any pending
DSRs will be called then. The delay is not large.


> What if the hardware is *not sensible* as per above
> explanation? what can be the repurcussions of this
> then? I guess the interrupt stack will be overflown.

Yes, that is exactly what will happen.

> Will there be any other issue apart from this?
> Just wondering, if deploying such kind of hardware
> will mean *dooomed* for the places where it is
> deployed? Has anyone on the list come across such kind
> of *not sensible* hardware so far?

Such hardware means that the HAL must stick to the sequential
interrupt model that most HALs implement by default.

-- 
Nick Garnett - eCos Kernel Architect
http://www.eCosCentric.com/


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss