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

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

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.