public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Michael Jones <mjones@linear.com>
To: "Lambrecht Jürgen" <J.Lambrecht@TELEVIC.com>
Cc: ecos discuss <ecos-discuss@sourceware.org>
Subject: Re: [ECOS] Scheduler startup question
Date: Thu, 27 Feb 2014 16:40:00 -0000	[thread overview]
Message-ID: <DD2DBB97-4736-487F-AF3F-FFDF71677DAA@linear.com> (raw)
In-Reply-To: <jbx041itlgmp5ctby5fmojvm.1393483201068@email.android.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

  reply	other threads:[~2014-02-27 16:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-27  6:40 Lambrecht Jürgen
2014-02-27 16:40 ` Michael Jones [this message]
2014-03-02 20:19 ` Michael Jones
2014-03-04 15:37   ` christophe
2014-03-04 15:58     ` Michael Jones
2014-03-04 16:17       ` christophe
2014-03-04 16:51         ` Michael Jones
2014-03-04 17:09           ` Michael Jones
  -- strict thread matches above, loose matches on Subject: below --
2014-02-27  5:06 Michael Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DD2DBB97-4736-487F-AF3F-FFDF71677DAA@linear.com \
    --to=mjones@linear.com \
    --cc=J.Lambrecht@TELEVIC.com \
    --cc=ecos-discuss@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).