[Xenomai-help] detect mode switches to primary mode

[Xenomai-help] detect mode switches to primary mode

[Peter Pastor]

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

Dear all,

I am running several boarder line threads that are running in primary mode
only when accessing some shared memory, otherwise I want them to run in
secondary mode. I have used rt_task_set_mode to warn me upon switches to
secondary modes, however, my question is, is there a similar way to detect
mode switches to primary mode ?

I have figured out a workaround using pthread_set_mode_np to force the
thread to run in secondary mode (after shared memory access) and right
before I force it back to primary mode do a printf and see whether I get a
warning of switching into secondary mode (if so, then I know that the thread
was running in primary mode, if not, then the thread was running in
secondary mode.)

Again, my question is, is there an elegant way to detect mode switches from
secondary mode to primary mode ?

THANKS,
 peter

[-- Attachment #2: Type: text/html, Size: 880 bytes --]

Re: [Xenomai-help] detect mode switches to primary mode

[Gilles Chanteperdrix]

Peter Pastor wrote:
> Dear all,
> 
> I am running several boarder line threads that are running in primary
> mode only when accessing some shared memory, otherwise I want them to
> run in secondary mode. I have used rt_task_set_mode to warn me upon
> switches to secondary modes, however, my question is, is there a similar
> way to detect mode switches to primary mode ?
> 
> I have figured out a workaround using pthread_set_mode_np to force the
> thread to run in secondary mode (after shared memory access) and right
> before I force it back to primary mode do a printf and see whether I get
> a warning of switching into secondary mode (if so, then I know that the
> thread was running in primary mode, if not, then the thread was running
> in secondary mode.)
> 
> Again, my question is, is there an elegant way to detect mode switches
> from secondary mode to primary mode ?

No there is not. The reason to detect switches from primary to secondary
mode is to debug issues of threads which should remain in primary mode,
nothing else. And pthread_set_mode_np(PTHREAD_PRIMARY) is deprecated.

If you have a borderline thread sharing memory with a primary-mode only
thread, you are supposed to protect the accesses to the shared memory
with a mutex, then the borderline thread will automatically switch to
primary mode when it acquires the mutex. When it gets out of this
critical section and it calls a function which requires running in
secondary mode, then it will switch automatically to secondary mode.

Next versions of Xenomai will get this borderline thread to switch
automatically to secondary mode when it releases the mutex (the patch
already exists).

-- 
                                                                Gilles.

Re: [Xenomai-help] detect mode switches to primary mode

[Gilles Chanteperdrix]

Peter Pastor Sampedro wrote:
> Hey Gilles,
> 
> Thanks for your prompt response !
> 
>> If you have a borderline thread sharing memory with a primary-mode only
>> thread, you are supposed to protect the accesses to the shared memory
>> with a mutex, then the borderline thread will automatically switch to
>> primary mode when it acquires the mutex. When it gets out of this
>> critical section and it calls a function which requires running in
>> secondary mode, then it will switch automatically to secondary mode.
> 
> That is exactly what I am doing. However, since I am linking my
> program against the posix skin, I may call some posix function in the
> non-real-time part of the boarder line thread which cause my thread to
> switch back to primary mode... which is exactly what I don't want it
> to do.
> 
> Anyways, thanks for letting me know that there is no clean way to see
> when/where mode switches from secondary to primary modes happen.

Posix function calls which cause this thread to switch to primary mode
require this to work correctly. So, you can not call them and hope to
remain in secondary mode. As explained here:
http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Compilation_flags.

Linking the application to Xenomai posix skin is not sufficient to have
this application use Xenomai services. The --wrap mechanism does this.
So, if you want to be sure to use Linux service instead of Xenomai
service, you should use the __real prefix.

In short, I do not understand what you are trying to do.

What about sending a small piece of code to explain it?
-- 
                                                                Gilles.

Re: [Xenomai-help] detect mode switches to primary mode

[Gilles Chanteperdrix]

Peter Pastor Sampedro wrote:
> Hey Gilles,
> 
> Thanks for your prompt response !
> 
>> If you have a borderline thread sharing memory with a primary-mode only
>> thread, you are supposed to protect the accesses to the shared memory
>> with a mutex, then the borderline thread will automatically switch to
>> primary mode when it acquires the mutex. When it gets out of this
>> critical section and it calls a function which requires running in
>> secondary mode, then it will switch automatically to secondary mode.
> 
> That is exactly what I am doing. However, since I am linking my
> program against the posix skin, I may call some posix function in the
> non-real-time part of the boarder line thread which cause my thread to
> switch back to primary mode... which is exactly what I don't want it
> to do.
> 
> Anyways, thanks for letting me know that there is no clean way to see
> when/where mode switches from secondary to primary modes happen.
> 
> Thanks,
>  peter

Ok. Got it. But there must be some kind of misunderstanding: a high
priority thread running in secondary mode is not what you want, because
it makes it interruptible by non real-time interrupt, bottom halves,
tasklets, etc destroying its guaranteed latencies... But a null priority
thread running in primary mode is harmless. Since it has a null
priority, it will not prevent high priority thread from running.

Something else: if you want to avoid issues, the mutex protecting the
shared memory area shared between a high priority thread and the border
line thread should have priority inheritance enabled.

-- 
                                                                Gilles.

Re: [Xenomai-help] detect mode switches to primary mode

[Peter Pastor]

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

Hey Gilles,

Sorry for all the confusion. I hope my little example pseudo code of the
boarder line thread makes things clear.

thread_loop()
{

// access memory that is shared with a real-time thread (that does not mode
switch)
// calling pthread_mutex_lock causes the current thread to switch to primary
mode (in case it is not already in primary mode)

  pthread_mutex_lock( &mutex1 );

// access shared memory, that is copy memory and nothing else !!

  pthread_mutex_unlock( &mutex1 );

// Now, I want the rest of the code to run in secondary mode !!
// therefore I could simply do a printf or...

#ifdef __XENO__
  pthread_set_mode_np(PTHREAD_PRIMARY, 0);
#endif

// The thread switched to secondary mode.
// Now, I process the data and e.g. display it using openGL or read from the
command line. I want this part of the code to run in secondary mode !!

// I am using the posix skin (/usr/xenomai/bin/xeno-config --skin posix
--cflags --ldflags) because I want to be able to compile the code in xenomai
and ensure real-time capabilities and also compile on a linux only system
for testing.

// However, the openGL code or libreadline for example might do a posix
function call and cause the thread switch back to primary mode which I don't
want !!! ...and want to detect.

}


My current approach to detect whether there was an unwanted mode switch from
secondary to primary in the non-real-time part of the thread is to detect
mode switches from primary to secondary using pthread_set_mode_np(0,
PTHREAD_WARNSW) and signal(SIGXCPU, warn_upon_switch)... and do the
following


thread_loop()
{

// to check there was an unwanted mode switches to primary mode (in the for
example openGL code) I simply do a printf
// and check whether this raises the SIGXCPU signal. If so, the thread was
running in primary mode, otherwise, the thread was running in secondary mode
(which is want I want)
// If the thread switched back and force inside the openGL code, I should
have noticed it since switching from primary to secondary is captured by the
SIGXCPU (is it?)

// here is the code...

#ifdef __XENO__
  printf("test\n");  // in case the thread is running in PRIMARY mode, this
will raise a SIGXCPU signal and we conclude that there was an unwanted mode
swicht from secondary to primary mode in the openGL code.
  pthread_set_mode_np(0,PTHREAD_PRIMARY); // this is unnecessary !!!
...since calling pthread_mutex_lock switches the thread to primary mode
automatically.
#endif

  pthread_mutex_lock( &mutex1 );
// access shared memory, that is copy memory and nothing else !!
  pthread_mutex_unlock( &mutex1 );

// switch back to SECONDARY mode
#ifdef __XENO__
  pthread_set_mode_np(PTHREAD_PRIMARY, 0);
#endif

// do non-real-time processing (e.g. openGL stuff, libreadline...).

}

The question is, is there a better way to detect this unwanted mode switches
from secondary to primary mode ?

I just read your last mail and it seems that there is still some sort of
misunderstanding..

>> A high priority thread running in secondary mode is not what you want...
Yes, that is true, however that is not want I am doing, correct ? The
boarder line thread (above) runs in primary mode for exactly the "three
lines of code" (1) lock mutex (2) access "shared" memory and (3) unlock
mutex
The rest of the code in the boarder line thread should be executed in
secondary mode where it can be preempted by the linux kernel, which is ok.
It does not influence the real-time thread that writes to the "shared"
memory, does it. There is no synchronization between the real-time thread
and the boarder line thread required !!! Thus, there is no guarantee that
the boarder line thread does not miss cycles (shared memory updates) of the
real-time thread, which is OK.

>> Something else: if you want to avoid issues, the mutex protecting the
>> shared memory area shared between a high priority thread and the border
>> line thread should have priority inheritance enabled.
I can see why "priority inheritance enabled" makes sense here (which is what
I do). Just to verify my understanding, priority inheritance gives the
boarder-line thread a higher priority once it is holding the lock in order
to have it run and release the mutex again. Otherwise the high-priority
thread may starve the system when trying to lock the mutex which is hold by
the lower priority (boarder-line) thread.

Thanks for all the clarifications,
 peter


On Sat, Nov 6, 2010 at 6:51 AM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> Peter Pastor wrote:
> > Dear all,
> >
> > I am running several boarder line threads that are running in primary
> > mode only when accessing some shared memory, otherwise I want them to
> > run in secondary mode. I have used rt_task_set_mode to warn me upon
> > switches to secondary modes, however, my question is, is there a similar
> > way to detect mode switches to primary mode ?
> >
> > I have figured out a workaround using pthread_set_mode_np to force the
> > thread to run in secondary mode (after shared memory access) and right
> > before I force it back to primary mode do a printf and see whether I get
> > a warning of switching into secondary mode (if so, then I know that the
> > thread was running in primary mode, if not, then the thread was running
> > in secondary mode.)
> >
> > Again, my question is, is there an elegant way to detect mode switches
> > from secondary mode to primary mode ?
>
> No there is not. The reason to detect switches from primary to secondary
> mode is to debug issues of threads which should remain in primary mode,
> nothing else. And pthread_set_mode_np(PTHREAD_PRIMARY) is deprecated.
>
> If you have a borderline thread sharing memory with a primary-mode only
> thread, you are supposed to protect the accesses to the shared memory
> with a mutex, then the borderline thread will automatically switch to
> primary mode when it acquires the mutex. When it gets out of this
> critical section and it calls a function which requires running in
> secondary mode, then it will switch automatically to secondary mode.
>
> Next versions of Xenomai will get this borderline thread to switch
> automatically to secondary mode when it releases the mutex (the patch
> already exists).
>
> --
>                                                                 Gilles.
>

[-- Attachment #2: Type: text/html, Size: 7228 bytes --]

Re: [Xenomai-help] detect mode switches to primary mode

[Gilles Chanteperdrix]

Peter Pastor wrote:
> Hey Gilles,
> 
> Sorry for all the confusion. I hope my little example pseudo code of the
> boarder line thread makes things clear.
> 
> thread_loop()
> {
> 
> // access memory that is shared with a real-time thread (that does not
> mode switch)
> // calling pthread_mutex_lock causes the current thread to switch to
> primary mode (in case it is not already in primary mode)
> 
>   pthread_mutex_lock( &mutex1 );
> 
> // access shared memory, that is copy memory and nothing else !!
> 
>   pthread_mutex_unlock( &mutex1 );
> 
> // Now, I want the rest of the code to run in secondary mode !!
> // therefore I could simply do a printf or...
> 
> #ifdef __XENO__
>   pthread_set_mode_np(PTHREAD_PRIMARY, 0);
> #endif

This is not needed, the thread will swtich to secondary mode when needed.

> 
> // The thread switched to secondary mode.
> // Now, I process the data and e.g. display it using openGL or read from
> the command line. I want this part of the code to run in secondary mode !!
> 
> // I am using the posix skin (/usr/xenomai/bin/xeno-config --skin posix
> --cflags --ldflags) because I want to be able to compile the code in
> xenomai and ensure real-time capabilities and also compile on a linux
> only system for testing.
> 
> // However, the openGL code or libreadline for example might do a posix
> function call and cause the thread switch back to primary mode which I
> don't want !!! ...and want to detect.

No, dynamic libraries will not call xenomai posix skin functions,
unless, when making the .so, you passed the --wrap flag. Once the .so is
made, --wrap has no effect.

> 
> }
> 
> 
> My current approach to detect whether there was an unwanted mode switch
> from secondary to primary in the non-real-time part of the thread is to
> detect mode switches from primary to secondary using
> pthread_set_mode_np(0, PTHREAD_WARNSW) and signal(SIGXCPU,
> warn_upon_switch)... and do the following
> 
> 
> thread_loop()
> {
> 
> // to check there was an unwanted mode switches to primary mode (in the
> for example openGL code) I simply do a printf
> // and check whether this raises the SIGXCPU signal. If so, the thread
> was running in primary mode, otherwise, the thread was running in
> secondary mode (which is want I want)
> // If the thread switched back and force inside the openGL code, I
> should have noticed it since switching from primary to secondary is
> captured by the SIGXCPU (is it?)
> 
> // here is the code...
> 
> #ifdef __XENO__
>   printf("test\n");  // in case the thread is running in PRIMARY mode,
> this will raise a SIGXCPU signal and we conclude that there was an
> unwanted mode swicht from secondary to primary mode in the openGL code.
>   pthread_set_mode_np(0,PTHREAD_PRIMARY); // this is unnecessary !!!
> ...since calling pthread_mutex_lock switches the thread to primary mode
> automatically.
> #endif
> 
>   pthread_mutex_lock( &mutex1 );
> // access shared memory, that is copy memory and nothing else !!
>   pthread_mutex_unlock( &mutex1 );
> 
> // switch back to SECONDARY mode
> #ifdef __XENO__
>   pthread_set_mode_np(PTHREAD_PRIMARY, 0);
> #endif
> 
> // do non-real-time processing (e.g. openGL stuff, libreadline...).
> 
> }
> 
> The question is, is there a better way to detect this unwanted mode
> switches from secondary to primary mode ?

There is no such thing as unwanted mode switches from secondary mode to
primary mode.


-- 
                                                                Gilles.

Re: [Xenomai-help] detect mode switches to primary mode

[Peter Pastor]

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

Hey Gilles,

>> There is no such thing as unwanted mode switches from secondary mode to
primary mode.
Really ?? I want to ensure that my boarder line thread runs in SECONDARY
mode except when it is accessing the shared memory. The reason for that is
that I want linux to be able to preempt that thread if necessary. I have
enabled the Xenomai watchdog to kill real-time threads when they starve the
linux kernel. Thus, the result is that this watchdog kills (or sometimes
only preempts?) my boarder line thread (preempting is OK, but killing is
NOT). I see that the watchdog kicked in in the logs (dmesg). This happens
roughly every 5-10min or so... My idea is, that if I force the thread to run
in secondary mode (after accessing the shared memory), it will be a regular
linux thread (and can be preempted). Thus, having it switch to primary mode
is unwanted, is it ?

What am I missing here ?

Thanks,
 peter





On Sat, Nov 6, 2010 at 11:20 AM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> Peter Pastor wrote:
> > Hey Gilles,
> >
> > Sorry for all the confusion. I hope my little example pseudo code of the
> > boarder line thread makes things clear.
> >
> > thread_loop()
> > {
> >
> > // access memory that is shared with a real-time thread (that does not
> > mode switch)
> > // calling pthread_mutex_lock causes the current thread to switch to
> > primary mode (in case it is not already in primary mode)
> >
> >   pthread_mutex_lock( &mutex1 );
> >
> > // access shared memory, that is copy memory and nothing else !!
> >
> >   pthread_mutex_unlock( &mutex1 );
> >
> > // Now, I want the rest of the code to run in secondary mode !!
> > // therefore I could simply do a printf or...
> >
> > #ifdef __XENO__
> >   pthread_set_mode_np(PTHREAD_PRIMARY, 0);
> > #endif
>
> This is not needed, the thread will swtich to secondary mode when needed.
>
> >
> > // The thread switched to secondary mode.
> > // Now, I process the data and e.g. display it using openGL or read from
> > the command line. I want this part of the code to run in secondary mode
> !!
> >
> > // I am using the posix skin (/usr/xenomai/bin/xeno-config --skin posix
> > --cflags --ldflags) because I want to be able to compile the code in
> > xenomai and ensure real-time capabilities and also compile on a linux
> > only system for testing.
> >
> > // However, the openGL code or libreadline for example might do a posix
> > function call and cause the thread switch back to primary mode which I
> > don't want !!! ...and want to detect.
>
> No, dynamic libraries will not call xenomai posix skin functions,
> unless, when making the .so, you passed the --wrap flag. Once the .so is
> made, --wrap has no effect.
>
> >
> > }
> >
> >
> > My current approach to detect whether there was an unwanted mode switch
> > from secondary to primary in the non-real-time part of the thread is to
> > detect mode switches from primary to secondary using
> > pthread_set_mode_np(0, PTHREAD_WARNSW) and signal(SIGXCPU,
> > warn_upon_switch)... and do the following
> >
> >
> > thread_loop()
> > {
> >
> > // to check there was an unwanted mode switches to primary mode (in the
> > for example openGL code) I simply do a printf
> > // and check whether this raises the SIGXCPU signal. If so, the thread
> > was running in primary mode, otherwise, the thread was running in
> > secondary mode (which is want I want)
> > // If the thread switched back and force inside the openGL code, I
> > should have noticed it since switching from primary to secondary is
> > captured by the SIGXCPU (is it?)
> >
> > // here is the code...
> >
> > #ifdef __XENO__
> >   printf("test\n");  // in case the thread is running in PRIMARY mode,
> > this will raise a SIGXCPU signal and we conclude that there was an
> > unwanted mode swicht from secondary to primary mode in the openGL code.
> >   pthread_set_mode_np(0,PTHREAD_PRIMARY); // this is unnecessary !!!
> > ...since calling pthread_mutex_lock switches the thread to primary mode
> > automatically.
> > #endif
> >
> >   pthread_mutex_lock( &mutex1 );
> > // access shared memory, that is copy memory and nothing else !!
> >   pthread_mutex_unlock( &mutex1 );
> >
> > // switch back to SECONDARY mode
> > #ifdef __XENO__
> >   pthread_set_mode_np(PTHREAD_PRIMARY, 0);
> > #endif
> >
> > // do non-real-time processing (e.g. openGL stuff, libreadline...).
> >
> > }
> >
> > The question is, is there a better way to detect this unwanted mode
> > switches from secondary to primary mode ?
>
> There is no such thing as unwanted mode switches from secondary mode to
> primary mode.
>
>
> --
>                                                                 Gilles.
>

[-- Attachment #2: Type: text/html, Size: 5732 bytes --]

Re: [Xenomai-help] detect mode switches to primary mode

[Gilles Chanteperdrix]

Peter Pastor wrote:
> Hey Gilles,
> 
>>> There is no such thing as unwanted mode switches from secondary mode
> to primary mode.
> Really ?? I want to ensure that my boarder line thread runs in SECONDARY
> mode except when it is accessing the shared memory. The reason for that
> is that I want linux to be able to preempt that thread if necessary. I
> have enabled the Xenomai watchdog to kill real-time threads when they
> starve the linux kernel. Thus, the result is that this watchdog kills
> (or sometimes only preempts?) my boarder line thread (preempting is OK,
> but killing is NOT). I see that the watchdog kicked in in the logs
> (dmesg). This happens roughly every 5-10min or so... My idea is, that if
> I force the thread to run in secondary mode (after accessing the shared
> memory), it will be a regular linux thread (and can be preempted). Thus,
> having it switch to primary mode is unwanted, is it ?
> 
> What am I missing here ?

If the watchdog kills a thread, it means that the thread has an infinite
loop. The bug is this infinite loop, not the fact that the thread is
running in primary mode. You can install a handler for the watchdog
signal to see where the infinite loop is.

-- 
                                                                Gilles.