Peter Pastor Sampedro wrote:
> Hey Gilles,
>
> Thanks for your prompt response !
>
>> 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.
>
> That is exactly what I am doing. However, since I am linking my
> program against the posix skin, I may call some posix function in the
> non-real-time part of the boarder line thread which cause my thread to
> switch back to primary mode... which is exactly what I don't want it
> to do.
>
> Anyways, thanks for letting me know that there is no clean way to see
> when/where mode switches from secondary to primary modes happen.
>
> Thanks,
> peter
Ok. Got it. But there must be some kind of misunderstanding: a high
priority thread running in secondary mode is not what you want, because
it makes it interruptible by non real-time interrupt, bottom halves,
tasklets, etc destroying its guaranteed latencies... But a null priority
thread running in primary mode is harmless. Since it has a null
priority, it will not prevent high priority thread from running.
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.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
