>Sent: Monday, May 11, 2020 1:10 PM > >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?
Not related to XDDP; in SCHED_FIFO, highest priority thread can always occupy CPU, no any time slot for lower pro threads; if highest pri thread has bug, ex. a dead loop, assume only one core system, the core will just occupied, the system looks like hang up. If no watchdog to trigger a reboot, the dead loop will forever, then the system cannot response to anything else; BR fino > > Thank you for your attention. > Look forward to hearing from you. > >Meng, Fino <fino.m...@intel.com <mailto: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 >
