[Xenomai-help] Sharing data between multiple Xenomai tasks in the same process

[Xenomai-help] Sharing data between multiple Xenomai tasks in the same process

[Sherk Chung]

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

Hi folks, I have some basic questions regarding having multiple task
threads running in a Xenomai process.  

 

We would like to have a Xenomai process with multiple threads (tasks).
The primary task needs to hard-real-time, the others secondary ones will
be using non-real-time drivers so they will be degraded to
soft-real-time.  In order to share information between all the tasks, we
are thinking of doing something simple, such as having a global
structure that all threads can access.  I understand that we'll need
mutexes to preserve data integrity, and that the primary task might be
caught waiting for a lock to release which might cause timing jitter.
But assuming we have that issue under control, are here any other
Xenomai related issues that we should be aware of that might cause the
hard-real-time task to degrade to soft-real-time by doing this?

 

Some things I'd like to verify:

-        It's generally ok to run multiple Xenomai tasks within a single
process.

-        If one of the secondary tasks is degraded to soft-real-time,
the degradation will be limited only to that particular secondary task,
not to the entire process (so the primary thread will remain
hard-real-time)

-        Having a global structure that all tasks can access is an
acceptable way to share data across Xenomai tasks (no
pipes/queues/sharedmem necessary in this scenario)

-        There is no risk of the primary task degrading to
soft-real-time by sharing a global structure with the secondary tasks
that are degraded to soft-real-time

 

I'm guessing there is no issue but just wanted to make sure.

 

Thanks.

 

-Sherk

 


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

Re: [Xenomai-help] Sharing data between multiple Xenomai tasks in the same process

[Gilles Chanteperdrix]

Sherk Chung wrote:
> Hi folks, I have some basic questions regarding having multiple task
> threads running in a Xenomai process. 
> 
>  
> 
> We would like to have a Xenomai process with multiple threads (tasks). 
> The primary task needs to hard-real-time, the others secondary ones will
> be using non-real-time drivers so they will be degraded to
> soft-real-time.  In order to share information between all the tasks, we
> are thinking of doing something simple, such as having a global
> structure that all threads can access.  I understand that we’ll need
> mutexes to preserve data integrity, and that the primary task might be
> caught waiting for a lock to release which might cause timing jitter. 
> But assuming we have that issue under control, are here any other
> Xenomai related issues that we should be aware of that might cause the
> hard-real-time task to degrade to soft-real-time by doing this?
> 
>  
> 
> Some things I’d like to verify:
> 
> -        It’s generally ok to run multiple Xenomai tasks within a single
> process.
> 
> -        If one of the secondary tasks is degraded to soft-real-time,
> the degradation will be limited only to that particular secondary task,
> not to the entire process (so the primary thread will remain hard-real-time)
> 
> -        Having a global structure that all tasks can access is an
> acceptable way to share data across Xenomai tasks (no
> pipes/queues/sharedmem necessary in this scenario)
> 
> -        There is no risk of the primary task degrading to
> soft-real-time by sharing a global structure with the secondary tasks
> that are degraded to soft-real-time
> 
>  
> 
> I’m guessing there is no issue but just wanted to make sure.

Hi,

It is Ok to protect shared data between a critical task and a non
critical task with a mutex, provided that:
- you enable priority inheritance for the mutex;
- the non critical thread never calls a Linux service while holding the
mutex.

Xenomais is able to detect such situation and to send the faulting
thread a signal in that case: enable CONFIG_XENO_OPT_DEBUG_SYNCH_RELAX
in the configuration, and set, for the critical thread, the T_WARNSW bit
with rt_task_set_mode if using the native API, or the PTHREAD_WARNSW bit
with pthread_set_mode_np if using the POSIX API.

-- 
					    Gilles.