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