Q: about mutex lock bettween rt thread and nrt thread.

Q: about mutex lock bettween rt thread and nrt thread.

[孙世龙]

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.

RE: Q: about mutex lock bettween rt thread and nrt thread.

[Meng, Fino]

>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

Re: Q: about mutex lock bettween rt thread and nrt thread.

[孙世龙]

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.meng@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
>

RE: Q: about mutex lock bettween rt thread and nrt thread.

[Meng, Fino]

>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.meng@intel.com <mailto:fino.meng@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
>