This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: eCOS calling path question?Thanks a lot.


On Sat, 31 May 2003 22:53:46 +0100
<jameshq@liverpool.ac.uk> wrote:

> Hi all:
>    I have a question related to the calling path of the eCOS when
> using Cyg_Flag::wait( ).
> for example:
> 
> Thread 1 : priority #11
> Thread 2 : priority #12
> Thread 3 : priority #12
> Time Slicing enabled
> 
> When Thread 1 loaded and run (sched_lock=0) --> when Cyg_Flag::wait( )
> called in Thread 1 (sched_lock=0)--> Cyg_Scheduler::lock()
> (sched_lock=1) 
> --> set Thread 1 to Wait state --> call sleep( ) and sleep thread 1
> (sched_lock=1) --> Cyg_Scheduler::reschedule()--> unlock_inner( 1 )-->
> switch 
> context and run Thread 2 --> Real Time Clock happens --> RTC IRQ
> increment sched_lock by 1 (sched_lock=2) --> interrupt_end( ) -->
> unlock( ) -->
> unlock_inner() will not be called due to the sched_lock-1!=0, so
> RTC::dsr() will not be called also Thread 3 will not be able to get
> the time slot 
> to run (Thread 2 and 3 at the same priority) so what's going on here??
>

You should check the mailing list. There has been a previous
thread explaining the call path for interrupt handling, at least,
for HAL that are not implementing the "nesting" form of IT
handling. I'm mostly working with ARM, where there is
historically no "nesting", so when the RTC IRQ is serviced,
either we are in a pure thread, or a pure DSR, so the scenario
is well-bounded and already well described.

However, this seems not to match your behavior, because
sched_lock  is then ensure to be the cached copy if the
current thread's sched_lock, and when this rule is
not true, ITs are off.

If your question is just academic, you should check the
mailing list, and the useful big code comments explaining unlock_inner.

If you find this in a real environment that does not nesting
the only ~somewhat~ guess of your behavior, is that eCos
give hand to Thread 2, while this one is sleeping and no reasons
to get up. Such case would be a nightmare to debug.

May be, I  may help you more efficiently, if you could told me
what HAL was used, and exactly where (context)  the RTC IRQ were
serviced.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]