This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Scheduler startup question
- From: Michael Jones <mjones at linear dot com>
- To: Lambrecht Jürgen <J dot Lambrecht at TELEVIC dot com>
- Cc: ecos discuss <ecos-discuss at sourceware dot org>
- Date: Thu, 27 Feb 2014 09:39:54 -0700
- Subject: Re: Scheduler startup question
- Authentication-results: sourceware.org; auth=none
- References: <jbx041itlgmp5ctby5fmojvm dot 1393483201068 at email dot android dot com>
By tracing through a Cortex M application that works, I found that when the first thread is run, there is a loop at the bottom of the thread entry call that calls unlock until sched_lock is 0. Every thread entry does this.
This seems a bit dangerous to me, as the unlocking occurs anytime a new thread is created. I have to assume that the thread could not be entered when in a critical section between scheduler locks.
I'll look into that behavior and see if it is related to my BSD assertion.
On Feb 26, 2014, at 11:40 PM, Lambrecht Jürgen <J.Lambrecht@TELEVIC.com> wrote:
> As far as I know the scheduler is started after cyg_user_start(), used by your application to initialize everything. Do you use cyg_user_start?
>
>
> Verzonden vanaf Samsung Mobile
>
>
>
> -------- Oorspronkelijk bericht --------
> Van: Michael Jones <mjones@linear.com>
> Datum:
> Aan: ecos discuss <ecos-discuss@sourceware.org>
> Onderwerp: [ECOS] Scheduler startup question
>
>
> I have a question about proper scheduler locking startup behavior.
>
> The context is I am cleaning up my iMX6 HAL and attempting to make things work without a couple of kernel hacks I added to make it work.
>
> The question has to do with sched_lock. By default this has a value of 1, so during startup the scheduler is locked.
>
> When there is an interrupt, sched_lock is incremented in Vectors.S, and decremented in interrupt_end.
>
> However, I am getting an assert in sync.h which is part of the BSD stack. The assert is because it expects the lock to be zero.
>
> The question is, during the startup process, how does the lock get set to zero after initialization? Is it supposed to stay 1 while hardware is initialized and through all the constructors, etc? Is it cleared by the scheduler somehow? Is the HAL supposed to zero it at some point during startup?
>
> My HAL is part of the ARM hal, so if this is device specific, it is the ARM HAL I am working with.
>
> Mike
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss