Hi,
Thank you for your response.
>>If Head domain's interrupts & threads occupied CPU, the system may
deadlock there since nothing can kill them.
What do you mean? I could not get the idea.When this happen? And
how?Does it have relation to XDDP?
Thank you for your attention.
Look forward to hearing from you.
Meng, Fino <fino.m...@intel.com> 于2020年5月10日周日 下午10:17写道：
>
> >Sent: Sunday, May 10, 2020 1:12 PM
> >
> >Hi,
> >I think mutex lock should not be shared bettween rt thread and nrt
> thread, because if i use the posix mutex api
> >implemented by linux,it causes the rt thread switch to the secondary mode.
> >
> > As per the documentation(https://xenomai.org/documentation/
> >xenomai-3/html/xeno3prm/group__alchemy__mutex.html
> >#ga8f7db304bb5a839d81614f00c4cde145),
> >the mutex api implemented by xenomai could not be used in normal linux
> thread.
> >
> >So,how to share the same mutex bettween rt thread and nrt thread?Could
> you offer some guidance on that?
> >
> >Thank you for your attention.
> >Looking forward to hearing from you.
>
> I would like to say, if subconsciously want to use mutex or some other
> lock between Cobalt thread
> and Linux kernel thread, it's better find another pattern to exchange data
> other than a mutex/lock. For example,
> Cobalt thread continuous write data to a piece of memory, Linux kernel
> thread continuous read.
> This may lose some samples although, but can let Cobalt thread return
> immediately without blocking.
> If lose sample is not acceptable, try XDDP, Cobalt thread can also
> write&return without blocking.
> If Head domain's interrupts & threads occupied CPU, the system may
> deadlock there since nothing can kill them.
>
>
> BR / Fino (孟祥夫)
> Intel – IOTG Developer Enabling
>
