[Xenomai-help] handling threads within a pod

[Xenomai-help] handling threads within a pod

[Khalil GHORBAL]

Hi,

I'm trying to implement a new skin (IMA380) using xenomai framework.

When creating multiple xnthreads within a pod,
I didn't found a way to access or handle these threads.
Threads are linked to the global queue of a pod but how can I access to 
the other fields of xnthread structure ?

hope it was clear :)

Regards,
--
Khalil

Re: [Xenomai-help] handling threads within a pod

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

Khalil GHORBAL wrote:
> Hi,
> 
> I'm trying to implement a new skin (IMA380) using xenomai framework.

Cool. Just learned that IMA380 is similar to ARNIC 653. Sounds quite
interesting. Will there be real partitioning? Will we get the chance to
see/use the result some day?

> 
> When creating multiple xnthreads within a pod,
> I didn't found a way to access or handle these threads.
> Threads are linked to the global queue of a pod but how can I access to
> the other fields of xnthread structure ?
> 
> hope it was clear :)

Not really. Do you mean how to handle references to those threads, how
to pass them to the user and accept them back? Or do you mean how to
manipulate fields of the xnthread structure directly. The latter is
risky as you bypass the nucleus interface. Better check if some service
of the nucleus layer provide the required access. If not, elaborate what
kind of access you need.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] handling threads within a pod

[Khalil GHORBAL]

Jan Kiszka wrote:

>Khalil GHORBAL wrote:
>  
>
>>Hi,
>>
>>I'm trying to implement a new skin (IMA380) using xenomai framework.
>>    
>>
>
>Cool. Just learned that IMA380 is similar to ARNIC 653. Sounds quite
>interesting. Will there be real partitioning? Will we get the chance to
>see/use the result some day?
>  
>
Thank you for your answer Jan.

As I'm not the only concerned I can't give an answer rightnow,
but if it depends only on me, yes, I'll share my work with every body, 
hoping it'll be useful.

>  
>
>>When creating multiple xnthreads within a pod,
>>I didn't found a way to access or handle these threads.
>>Threads are linked to the global queue of a pod but how can I access to
>>the other fields of xnthread structure ?
>>
>>hope it was clear :)
>>    
>>
>
>Not really. Do you mean how to handle references to those threads, how
>to pass them to the user and accept them back? Or do you mean how to
>manipulate fields of the xnthread structure directly. The latter is
>risky as you bypass the nucleus interface. Better check if some service
>of the nucleus layer provide the required access. If not, elaborate what
>kind of access you need.
>  
>
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.

I still misunderstood the function of global queue and how the pod 
schedule existing threads.

>Jan
>
>  
>
Thank you in advance.

Best Regards,
--
Khalil

Re: [Xenomai-help] handling threads within a pod

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3478 bytes --]

Khalil GHORBAL wrote:
> Jan Kiszka wrote:
> 
>> Khalil GHORBAL wrote:
>>  
>>
>>> Hi,
>>>
>>> I'm trying to implement a new skin (IMA380) using xenomai framework.
>>>   
>>
>> Cool. Just learned that IMA380 is similar to ARNIC 653. Sounds quite
>> interesting. Will there be real partitioning? Will we get the chance to
>> see/use the result some day?
>>  
>>
> Thank you for your answer Jan.
> 
> As I'm not the only concerned I can't give an answer rightnow,
> but if it depends only on me, yes, I'll share my work with every body,
> hoping it'll be useful.

Well, if you need some more argument for persuading those who may
decide: A contributed skin will also be easier to maintain. We may have
to adapt interfaces during future development, and if your code is part
of Xenomai then, it will be included in the required changes. Or the
modification will be reconsidered if it harms your skin unacceptably.

> 
>>  
>>
>>> When creating multiple xnthreads within a pod,
>>> I didn't found a way to access or handle these threads.
>>> Threads are linked to the global queue of a pod but how can I access to
>>> the other fields of xnthread structure ?
>>>
>>> hope it was clear :)
>>>   
>>
>> Not really. Do you mean how to handle references to those threads, how
>> to pass them to the user and accept them back? Or do you mean how to
>> manipulate fields of the xnthread structure directly. The latter is
>> risky as you bypass the nucleus interface. Better check if some service
>> of the nucleus layer provide the required access. If not, elaborate what
>> kind of access you need.
>>  
>>
> 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.

Looks like you'll be the first user of extinfo then. I wonder what it
should be useful for given that one normally embeds xnthread_t in a
container structure like this:

struct my_thread {
	xnthread_t thread_base;
	some_type some_additional_data;
};

Then, if you have a reference to a xnthread, you can easily resolve it
to your container thread:

my_thread_ptr = container_of(xnthread_ptr, struct my_thread,
			     thread_base);

To identify if this extension is valid, you can use the magic field in
xnthread (xnthread_get/set_magic).

[I'm picking on this as I feel like we could remove extinfo in the
future, but I might oversee some legitimate use-case right now.]

> 
> 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.

Again, you can use the magic field. Or you can start maintaining your
own list of threads. The posix skin does it like this.

> 
> I still misunderstood the function of global queue and how the pod
> schedule existing threads.

The global queue is mostly there for informative purposes, e.g. /proc
listings. There is also a usage scenario wrt round-robin. But scheduling
takes place based on the runqueues of each CPU.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] handling threads within a pod

[Philippe Gerum]

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.

Re: [Xenomai-help] handling threads within a pod

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3120 bytes --]

Philippe Gerum wrote:
> 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.
> 

The way described above is certainly the preferred one for a first
approach. But I wonder if switching full schedules isn't more efficient,
scalable, and simply more "partitioned" than this O(n) method. I haven't
looked at details yet, but is there anything that may prevent such
"hard" switch ATM?

Another topic that my addiction to perfectionism brought to my mind are
partitioned timers. Anyway, once we switch whole schedules, shouldn't
those timers be switched automatically as well? Considering that a
partition switch would be triggered by a timer, one would only have to
restart the timer IRQ over the new sched to continue. In theory...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] handling threads within a pod

[Philippe Gerum]

On Fri, 2006-07-14 at 17:58 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > 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.
> > 
> 
> The way described above is certainly the preferred one for a first
> approach.

It's the only sane one I see without changing the real-time pod design.
Additionally, ima380 or arinc653 over Linux must be aimed at simulation
purposes, otherwise, this would make no sense. In such context,  it
should be possible to relax constraints about runtime performances
somehow, even if predictability must still be guaranted (hopefully, no
one really wants to run partitions with an insane number of processes).

>  But I wonder if switching full schedules isn't more efficient,
> scalable, and simply more "partitioned" than this O(n) method. I haven't
> looked at details yet, but is there anything that may prevent such
> "hard" switch ATM?
> 

The fact that no "partition" abstraction exists at pod level. The way to
implement this would be to get first the pluggable scheduler
infrastructure, and see a partitioned system as just some
(meta-)scheduler holding sub-schedulers. We just can't pay the price of
adding the partition abstraction to the vast majority of mimicked RTOSes
that don't care about such twisted design (IIRC, temporal partitioning
for arinc653 was basically a kludge around hardware constraints for
simulating multi-node activity). So this abstraction should be better
implemented as some meta scheduler add-on.

> Another topic that my addiction to perfectionism brought to my mind are
> partitioned timers. Anyway, once we switch whole schedules, shouldn't
> those timers be switched automatically as well? Considering that a
> partition switch would be triggered by a timer, one would only have to
> restart the timer IRQ over the new sched to continue. In theory...
> 

Since each resource would need to be associated to a given partition,
timers would have to follow the common rule, which opens a number of
issues as to reduce the impact of built-in partitioning for skins that
don't care about it. Quite frankly, I must admit that my bain cycles are
not particularly focused on that issue, right now.

> Jan
> 
-- 
Philippe.

Re: [Xenomai-help] handling threads within a pod

[Jan Kiszka]

Philippe Gerum wrote:
> ...
> 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);
> 	}
> }

I wonder if there isn't the risk of mixing up the schedule inside the
partitions by suspending/resuming this way. I think the order of
resuming those threads that were ready before must match the original
order in the ready-queue at suspension time.

> 
> 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.
> 

Jan

Re: [Xenomai-help] handling threads within a pod

[Philippe Gerum]

On Mon, 2006-07-17 at 09:45 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > ...
> > 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);
> > 	}
> > }
> 
> I wonder if there isn't the risk of mixing up the schedule inside the
> partitions by suspending/resuming this way. I think the order of
> resuming those threads that were ready before must match the original
> order in the ready-queue at suspension time.
> 

It's a sketchy representation. The real implementation would have to
move all runnable threads to a preemption queue.

> > 
> > 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.
> > 
> 
> Jan
-- 
Philippe.