Re: [ECOS] cyg_scheduler_lock() understanding...

["Stefan Sommerfeld" <sommerfeld at mikrom dot de>]

Hi,
> > I still search for the delay DSR and found it that the DSR will be
> > permitted due to a scheduler_lock. I quickly have some question while 
> > going
> > deeper into ecos.
> >
> > Does the scheduler_lock also permits the thread switching? Or is it
> > possible that the scheduler switches to another thread while in lock 
> > mode?
> >
> > If thread switching is permitted, how could the scheduler_lock be higher
> > than one if no dsr or isr calls scheduler_lock()?
>
> Actually, every ISR causes a scheduler lock (it's part of the entry
> protocol into the system).  So, if the scheduler was locked for some
> other reason before the ISR happened, it will still be locked when it
> finishes and DSR processing will be postponed until it is freed (i.e.
> the scheduler lock value returns to zero).
>
> You can determine, in great detail, what's happening here by enabling
> the system trace/log features.  This will tell you when the scheduler
> gets locked (and where), when interrupts occur, etc.
Aha... i see. So scheduler can only be locked by a thread (one time) and by 
multiple irq's. What i see are sometimes delays above 10ms between lock and 
unlock. Is the unlock_inner() scheduler method save? Or can it be 
interrupted by in irq which then causes the lock counter to change?

My problems appear after a longer time (more then 10 mins), so heavy output 
would not help :). I already run my software with an ecos which includes 
asserts. Everything seem to be fine, but the scheduler_lock load increases. 
I'll do further investigation on the irq load.

Bye...

BTW: I found and fixed the serial 16x5x problem i wrote you about 
yesterday. It was caused by disabling the uart by writing a zero to ier. 
Patch will follow after some more tests. 


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