All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Everett Wang <everteq@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] task management, multi-thread, multi-core
Date: Wed, 07 Jul 2010 12:21:29 +0200	[thread overview]
Message-ID: <4C345529.8010309@domain.hid> (raw)
In-Reply-To: <AANLkTilmN6HTqYAcEv5qTqYhpjgBiMYQAPvPwCnynAHu@domain.hid>

Everett Wang wrote:
> Hi All,
> 
> I am working on a navigation program that has two realtime tasks. One
> is a high priority one executed in a higher frequency. Another task
> runs about 1/10th of the first one, but requires substantially more
> CPU computations. I am using an atom board which has dual threads
> capability. I am worried that the second task can block the execution
> of the first one until it finishs all the calculations. Can this
> happen in a dual thread and/or dual core CPU? If yes, should I break
> the task two into small chunks and let the task one to send a trigger
> to
> execute one chunk at a time? I know it is not xenomai specific
> question and I have tried to read manual or other documents trying to
> figure
> it out.

You did not tell us how was the priority of the second task, but since
you told us that the first task was high priority, I have to guess that
the second task is lower priority.

On an uni-processor machine, the priorities are used by the scheduler to
schedule your tasks, so, if a low priority task could prevent a high
priority task from running, the scheduler would need to be fixed.

On a multi-processor machine, you have to set the "affinity" of the
tasks to pin the tasks on a given cpu. On each cpu, tasks are scheduled
following their priorities.

> 
> I have read that tasks require more resources than threads in Linux.
> The inter-threads communication is also more efficient than that of
> tasks. Are these also true for xenomai realtime OS? Should I create
> threads instead of tasks?
> 
> 
> Any suggestions are welcome. Thanks for reading. :-)

task is an informal term which may mean process or thread depending on
the context. So, I guess what you mean is "process" instead of task. The
difference between processes and threads is that changing context
between processes requires changing the memory mapping, which is an
heavy operation. On the other hand, processes provide an isolation that
threads do not provide. So, choosing threads or processes is not only a
matter of performances (otherwise, we would all run Linux without MMU,
since in that case, everything is essentially a thread).

> 
> Everett
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 
					    Gilles.


  reply	other threads:[~2010-07-07 10:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-07  9:56 [Xenomai-help] task management, multi-thread, multi-core Everett Wang
2010-07-07 10:21 ` Gilles Chanteperdrix [this message]
2010-07-07 10:49   ` Everett Wang
2010-07-07 11:24     ` Gilles Chanteperdrix
2010-07-07 12:44       ` Everett Wang
2010-07-07 12:51         ` Gilles Chanteperdrix
2010-07-07 14:28           ` Everett Wang

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=4C345529.8010309@domain.hid \
    --to=gilles.chanteperdrix@xenomai.org \
    --cc=everteq@domain.hid \
    --cc=xenomai@xenomai.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.