This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: cyg_scheduler_lock() understanding...
- From: Gary Thomas <gary at mlbassoc dot com>
- To: Stefan Sommerfeld <sommerfeld at mikrom dot de>
- Cc: eCos Discussion <ecos-discuss at ecos dot sourceware dot org>
- Date: Tue, 18 Oct 2005 07:09:12 -0600
- Subject: Re: [ECOS] cyg_scheduler_lock() understanding...
- References: <003801c5d3e3$1c9968e0$8262fea9@nullnullsix>
On Tue, 2005-10-18 at 14:54 +0200, Stefan Sommerfeld wrote:
> 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.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss