All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Khalil GHORBAL <kg@domain.hid>
Cc: xenomai@xenomai.org, Jan Kiszka <jan.kiszka@domain.hid>
Subject: Re: [Xenomai-help] handling threads within a pod
Date: Fri, 14 Jul 2006 17:30:36 +0200	[thread overview]
Message-ID: <1152891036.5075.35.camel@domain.hid> (raw)
In-Reply-To: <44B60737.6050705@domain.hid>

On Thu, 2006-07-13 at 10:41 +0200, Khalil GHORBAL wrote:

> I'll give an example to explain the issue:
> Assuming having multiple threads in our active pod, these threads can be 
> in different states.
> The running thread have to get the *extinfo* field of thread named 
> "COM_THREAD" (for example) if exists.
> 
> All services of the nucleus need a *xnthread_t* structure to identify 
> the thread to treat, we can't have a list or something similar to sweep 
> existing threads. All I've found is the global queue, doubly-linked and 
> circular, which link all threads.
> So all informations I have is the number of threads and a way to go from 
> one holder to another
> without really be able to identify the thread and read the other fields.
> 

Forget about extinfo; you don't need this, and it's old cruft we are
going to kill in later versions anyway. What you need to handle
arinc653-like temporal partitioning is something along these lines:

struct ima380_process {
	xnthread_t threadbase;	/* process control block */
	xnholder_t ptlink;	/* link to next partition */
	/* ... */
};

struct ima380_partition {
	xnqueue_t procq;	/* chains ima380 processes */
	/* ... */
};

Don't refer to Xenomai's global thread queue, just manage your own
process queues populating a partition object abstraction.

Then use the XNHELD bit which has been specifically added as a
suspensive condition to handle temporal partitioning. This way, XNSUSP
remains available for suspending processes forcibly within a partition
(suspension bits are conjunctive). IOW, only the processes pertaining to
the running partition will have the XNHELD bit cleared, others will have
this bit set, and as such, suspended by the nucleus, which is what you
want.

void deactivate_partition (struct ima380_partition *pt)
{
	foreach(thread in pt->procq) {
		xnpod_suspend_thread(thread,XNHELD,XN_INFINITE,NULL);
	}
}

void activate_partition (struct ima380_partition *pt)
{
	foreach(thread in pt->procq) {
		xnpod_resume_thread(thread,XNHELD);
	}
}

The partition slicer can be implemented as a simple periodic timer,
whose handler activates existing partitions in a round-robin fashion.

FWIW, mimicking arinc653 over the nucleus is a no-brainer, so there's
good hope for IMA380.

-- 
Philippe.




  parent reply	other threads:[~2006-07-14 15:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-12 16:02 [Xenomai-help] handling threads within a pod Khalil GHORBAL
2006-07-12 16:23 ` Jan Kiszka
2006-07-13  8:41   ` Khalil GHORBAL
2006-07-13  9:11     ` Jan Kiszka
2006-07-14 15:30     ` Philippe Gerum [this message]
2006-07-14 15:58       ` Jan Kiszka
2006-07-14 19:04         ` Philippe Gerum
2006-07-17  7:45       ` Jan Kiszka
2006-07-17  8:04         ` Philippe Gerum

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=1152891036.5075.35.camel@domain.hid \
    --to=rpm@xenomai.org \
    --cc=jan.kiszka@domain.hid \
    --cc=kg@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.