Re: [Xenomai-help] General question on Native Skin tasks

[Jan Kiszka <jan.kiszka@domain.hid>]

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

Brian L. wrote:
>> Why do you create the non-rt threads also via rt_task_create? This just
>> introduces unneeded load on the RT subsystem.
> 
> I was under the impression that to interact with xenomai objects
> (RT_QUEUE, RT_MUTEX, etc), I needed to be in a xenomai thread. I
> assumed that because every mutex implementation I've seen has relied
> heavily on the underlying thread library (i.e. to sleep or yield) and
> mixing thread libraries seemed like a bad idea.
> 
> So, is this what you're suggesting:
> 
> - Link against pthreads AND native

By linking against native, you implicitly also link against pthread
(native threads are based on pthreads).

> - Start non-realtime threads using pthread_create and real-time
> threads using rt_task_create/rt_task_start

Yep.

> - use RT_MUTEX's/RT_QUEUE's for situations in which there is
> contention/communication among realtime and nonrealtime threads

Yes, but when blocking native services are invoked, the caller has to be
a native thread again. Only pure non-RT threads with no shared critical
paths can be plain pthreads. When in doubt, study the native
documentation regarding allowed contexts. The statement "switches to
primary mode" indicates that a native thread is required.

> - use pthreads mutexes/queues for situations of
> contention/communication among non-realtime threads

That's totally fine and also improve the efficiency (something that has
to be sacrificed for determinism sometimes).

> 
> It sounds workable to me, assuming the queues/mutexes/etc. don't stop
> working when both threading libraries are involved.

Hope I could clarify the situation.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]