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 >