Hi,Steve:
Thank you for the clarification.
>>Will ADOES wake up the related linux process at once when the head
>>domain write something to the XDDP node?* Or, the linux process
>>has to wait for the schedule of linux kernel, if the processor is
>>busy, it may wait for a long long time.
>The Linux process cannot wake up immediately, otherwise what would
>be the point of having an RT co-kernel if it didn't preempt the
>non-RT environment.
Yea，I can't agree more.
Imagine this scenario, your processor have 4 cores and you only have
one
RT process which has single thread.So, there are 3 cores could be used
for the linux processes at least. What i am interested in is that* if *
* the linux process wait to receive message through XDDP has to compete*
* for the cpu resources** with so many other linux processes .*
>If you're going to build code that makes a NRT process a subordinate
>of an RT process, you're going to have to employ some non-standard
>logic and get creative about how you deal with the inverted priority
>relationship that implicitly exists between the RT/NRT schedulers
>involved in that scenario.
What do you mean by " employ some non-standard logic"？Could you make
me more clearlly?
Thank you for your attention.
Look forward to hearing from you.
steve freyder <st...@freyder.net> 于2020年5月12日周二 上午11:43写道：
> On 5/11/2020 9:16 PM, 孙世龙 via Xenomai wrote:
>
> Hi,
> As i am using XDDP to transport messages bettween the head domain and
> linux domain(i mean there are two processes, one is rt process, the other
> is linux process.),I wonder that when the linux process could recieve the
> message？
> *Will ADOES wake up the related linux process at once when the head
> domain write something to the XDDP node?* Or, the linux process has to wait
> for the schedule of linux kernel, if the processor is busy, it may wait for
> a long long time.
>
> Thank you for your attention.
> Looking forward to hearing from you.
>
> The Linux process cannot wake up immediately, otherwise what would be the
> point of having an RT co-kernel if it didn't preempt the non-RT environment.
>
>
> If the RT process wishes to give the non-RT process an opportunity to run
> in order to receive the just-sent message, it had better relinquish the
> CPU. Inserting an rt_sleep() call (or equivalent) might be one
> (inelegant?) option, but certainly nothing in iPipe or anything at that
> layer is going to magically solve that problem for you.
>
>
> If you're going to build code that makes a NRT process a subordinate of an
> RT process, you're going to have to employ some non-standard logic and get
> creative about how you deal with the inverted priority relationship that
> implicitly exists between the RT/NRT schedulers involved in that scenario.
> XDDP is a bidirectional data relay, not a scheduler.
>
>
> Regards,
>
> Steve
>
>
>
