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 <
[email protected]> 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.
>
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
