[Xenomai-help] Is rt_task_set_mode( T_PRIMARY, 0, 0 ) temporary ?

[Xenomai-help] Is rt_task_set_mode( T_PRIMARY, 0, 0 ) temporary ?

[Peter Soetens]

Hi,

Is it possible that this call only clears the T_PRIMARY flag temporary, and 
that after 'some' rt_ call, the flag is set again ? 

I tried to check this with rt_task_inquire(	task, &info ) and check  
info.status & XNRELAX but that always returned false.

Peter
-- 
Peter Soetens -- FMTC -- <http://www.fmtc.be>

Re: [Xenomai-help] Is rt_task_set_mode( T_PRIMARY, 0, 0 ) temporary ?

[Philippe Gerum]

Peter Soetens wrote:
> Hi,
> 
> Is it possible that this call only clears the T_PRIMARY flag temporary, and 
> that after 'some' rt_ call, the flag is set again ? 
>

Any potentially blocking rt-syscall for instance, occurring between 
rt_task_set_mode() and rt_task_inquire(), would indeed switch the thread 
back to primary, clearing the XNRELAX bit from the status.

> I tried to check this with rt_task_inquire(	task, &info ) and check  
> info.status & XNRELAX but that always returned false.
> 
> Peter

Re: [Xenomai-help] Is rt_task_set_mode( T_PRIMARY, 0, 0 ) temporary ?

[Peter Soetens]

On Monday 14 January 2008 21:43:53 Philippe Gerum wrote:
> Peter Soetens wrote:
> > Hi,
> >
> > Is it possible that this call only clears the T_PRIMARY flag temporary,
> > and that after 'some' rt_ call, the flag is set again ?
>
> Any potentially blocking rt-syscall for instance, occurring between
> rt_task_set_mode() and rt_task_inquire(), would indeed switch the thread
> back to primary, clearing the XNRELAX bit from the status.

Thanks, It would be nice to add this sentence to the API docs.

So how do I run a task permanently in secondary mode ? The reason I want to do 
this is two fold: We want to share xenomai native mutexes and semaphores 
between threads running in primary domain and threads running under the Linux 
scheduler. And we want a thread type that allows user code to go in endless 
loops without hanging the machine. In RTAI we did this creating an RTAI task 
which was run in the soft-rt mode.
I believe a plain posix thread can not use the 'native' interface ? 

Peter

-- 
Peter Soetens -- FMTC -- <http://www.fmtc.be>

Re: [Xenomai-help] Is rt_task_set_mode( T_PRIMARY, 0, 0 ) temporary ?

[Gilles Chanteperdrix]

On Jan 15, 2008 10:24 AM, Peter Soetens <peter.soetens@domain.hid> wrote:
> On Monday 14 January 2008 21:43:53 Philippe Gerum wrote:
> > Peter Soetens wrote:
> > > Hi,
> > >
> > > Is it possible that this call only clears the T_PRIMARY flag temporary,
> > > and that after 'some' rt_ call, the flag is set again ?
> >
> > Any potentially blocking rt-syscall for instance, occurring between
> > rt_task_set_mode() and rt_task_inquire(), would indeed switch the thread
> > back to primary, clearing the XNRELAX bit from the status.
>
> Thanks, It would be nice to add this sentence to the API docs.
>
> So how do I run a task permanently in secondary mode ? The reason I want to do
> this is two fold: We want to share xenomai native mutexes and semaphores
> between threads running in primary domain and threads running under the Linux
> scheduler.

A thread which blocks on a xenomai native mutex or semaphore will
switch to primary mode, it will not run under the Linux scheduler.

> And we want a thread type that allows user code to go in endless
> loops without hanging the machine. In RTAI we did this creating an RTAI task
> which was run in the soft-rt mode.

You should probably use a native task with priority 0, this task will
use the SCHED_OTHER policy when run by Linux scheduler, which means it
will not hang the machine. But of course, you will have to take care
that the loop does not take place in primary mode.

> I believe a plain posix thread can not use the 'native' interface ?

A plain posix thread can use some of the native interface services,
but not the blocking ones. Blocking a thread requires xenomai tasks
running in primary mode.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Is rt_task_set_mode( T_PRIMARY, 0, 0 ) temporary ?

[Gilles Chanteperdrix]

On Jan 15, 2008 11:06 AM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On Jan 15, 2008 10:24 AM, Peter Soetens <peter.soetens@domain.hid> wrote:
> > On Monday 14 January 2008 21:43:53 Philippe Gerum wrote:
> > > Peter Soetens wrote:
> > > > Hi,
> > > >
> > > > Is it possible that this call only clears the T_PRIMARY flag temporary,
> > > > and that after 'some' rt_ call, the flag is set again ?
> > >
> > > Any potentially blocking rt-syscall for instance, occurring between
> > > rt_task_set_mode() and rt_task_inquire(), would indeed switch the thread
> > > back to primary, clearing the XNRELAX bit from the status.
> >
> > Thanks, It would be nice to add this sentence to the API docs.
> >
> > So how do I run a task permanently in secondary mode ? The reason I want to do
> > this is two fold: We want to share xenomai native mutexes and semaphores
> > between threads running in primary domain and threads running under the Linux
> > scheduler.
>
> A thread which blocks on a xenomai native mutex or semaphore will
> switch to primary mode, it will not run under the Linux scheduler.
>
> > And we want a thread type that allows user code to go in endless
> > loops without hanging the machine. In RTAI we did this creating an RTAI task
> > which was run in the soft-rt mode.
>
> You should probably use a native task with priority 0, this task will
> use the SCHED_OTHER policy when run by Linux scheduler, which means it
> will not hang the machine. But of course, you will have to take care
> that the loop does not take place in primary mode.
>
> > I believe a plain posix thread can not use the 'native' interface ?
>
> A plain posix thread can use some of the native interface services,
> but not the blocking ones. Blocking a thread requires xenomai tasks
> running in primary mode.

The only IPC which allows communication between Xenomai threads and
Linux threads without one of them leaving its mode is the native
message pipe:
http://www.xenomai.org/documentation/trunk/html/api/index.html

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Is rt_task_set_mode( T_PRIMARY, 0, 0 ) temporary ?

[Gilles Chanteperdrix]

On Jan 15, 2008 11:22 AM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On Jan 15, 2008 11:06 AM, Gilles Chanteperdrix
>
> <gilles.chanteperdrix@xenomai.org> wrote:
> > On Jan 15, 2008 10:24 AM, Peter Soetens <peter.soetens@domain.hid> wrote:
> > > On Monday 14 January 2008 21:43:53 Philippe Gerum wrote:
> > > > Peter Soetens wrote:
> > > > > Hi,
> > > > >
> > > > > Is it possible that this call only clears the T_PRIMARY flag temporary,
> > > > > and that after 'some' rt_ call, the flag is set again ?
> > > >
> > > > Any potentially blocking rt-syscall for instance, occurring between
> > > > rt_task_set_mode() and rt_task_inquire(), would indeed switch the thread
> > > > back to primary, clearing the XNRELAX bit from the status.
> > >
> > > Thanks, It would be nice to add this sentence to the API docs.
> > >
> > > So how do I run a task permanently in secondary mode ? The reason I want to do
> > > this is two fold: We want to share xenomai native mutexes and semaphores
> > > between threads running in primary domain and threads running under the Linux
> > > scheduler.
> >
> > A thread which blocks on a xenomai native mutex or semaphore will
> > switch to primary mode, it will not run under the Linux scheduler.
> >
> > > And we want a thread type that allows user code to go in endless
> > > loops without hanging the machine. In RTAI we did this creating an RTAI task
> > > which was run in the soft-rt mode.
> >
> > You should probably use a native task with priority 0, this task will
> > use the SCHED_OTHER policy when run by Linux scheduler, which means it
> > will not hang the machine. But of course, you will have to take care
> > that the loop does not take place in primary mode.
> >
> > > I believe a plain posix thread can not use the 'native' interface ?
> >
> > A plain posix thread can use some of the native interface services,
> > but not the blocking ones. Blocking a thread requires xenomai tasks
> > running in primary mode.
>
> The only IPC which allows communication between Xenomai threads and
> Linux threads without one of them leaving its mode is the native
> message pipe:
> http://www.xenomai.org/documentation/trunk/html/api/index.html

Frames got me. I meant:
http://www.xenomai.org/documentation/trunk/html/api/group__pipe.html

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Is rt_task_set_mode( T_PRIMARY, 0, 0 ) temporary ?

[Peter Soetens]

On Tuesday 15 January 2008 11:06:13 Gilles Chanteperdrix wrote:
>
> A thread which blocks on a xenomai native mutex or semaphore will
> switch to primary mode, it will not run under the Linux scheduler.
>
> > And we want a thread type that allows user code to go in endless
> > loops without hanging the machine. In RTAI we did this creating an RTAI
> > task which was run in the soft-rt mode.
>
> You should probably use a native task with priority 0, this task will
> use the SCHED_OTHER policy when run by Linux scheduler, which means it
> will not hang the machine. But of course, you will have to take care
> that the loop does not take place in primary mode.

The native API says that the lowest priority is '1' and not '0'.
<http://www.xenomai.org/documentation/branches/v2.4.x/html/api/group__task.html#g03387550693c21d0223f739570ccd992>

Or do you suggest I should use pthread_setschedparam or similar after a call 
to rt_task_set_mode(T_PRIMARY, 0, 0 ) ?

>
> > I believe a plain posix thread can not use the 'native' interface ?
>
> A plain posix thread can use some of the native interface services,
> but not the blocking ones. Blocking a thread requires xenomai tasks
> running in primary mode.

Ok. Thanks for this clarification. It looks like I'll have to redesign some 
code to take into account these policies. I just wonder if staying in the 
primary domain after a 'blocking' call is what users of rt_task_set_mode() 
expect. Why are the flags not restored to what the user has set ? I'm just 
complaining from a user's perspective :-]

Peter
-- 
Peter Soetens -- FMTC -- <http://www.fmtc.be>

Re: [Xenomai-help] Is rt_task_set_mode( T_PRIMARY, 0, 0 ) temporary ?

[Gilles Chanteperdrix]

On Jan 15, 2008 1:34 PM, Peter Soetens <peter.soetens@domain.hid> wrote:
> On Tuesday 15 January 2008 11:06:13 Gilles Chanteperdrix wrote:
> >
> > A thread which blocks on a xenomai native mutex or semaphore will
> > switch to primary mode, it will not run under the Linux scheduler.
> >
> > > And we want a thread type that allows user code to go in endless
> > > loops without hanging the machine. In RTAI we did this creating an RTAI
> > > task which was run in the soft-rt mode.
> >
> > You should probably use a native task with priority 0, this task will
> > use the SCHED_OTHER policy when run by Linux scheduler, which means it
> > will not hang the machine. But of course, you will have to take care
> > that the loop does not take place in primary mode.
>
> The native API says that the lowest priority is '1' and not '0'.
> <http://www.xenomai.org/documentation/branches/v2.4.x/html/api/group__task.html#g03387550693c21d0223f739570ccd992>
>
> Or do you suggest I should use pthread_setschedparam or similar after a call
> to rt_task_set_mode(T_PRIMARY, 0, 0 ) ?

The null priority is a (relatively) recent addition, so, maybe the
docs are not yet up to date.

>
> >
> > > I believe a plain posix thread can not use the 'native' interface ?
> >
> > A plain posix thread can use some of the native interface services,
> > but not the blocking ones. Blocking a thread requires xenomai tasks
> > running in primary mode.
>
> Ok. Thanks for this clarification. It looks like I'll have to redesign some
> code to take into account these policies. I just wonder if staying in the
> primary domain after a 'blocking' call is what users of rt_task_set_mode()
> expect. Why are the flags not restored to what the user has set ? I'm just
> complaining from a user's perspective :-]

The current policy is the lazy approach: mode switches occur only when
needed. This results in fewer mode switches, but this may mean that
you should use rt_task_set_mode from time to time if you want to force
a mode.

-- 
                                               Gilles Chanteperdrix