<div dir="auto"><div>Thanks for your answer.<br><br><div class="gmail_quote"><div dir="ltr">Le jeu. 22 nov. 2018 12:51, Juan Ignacio Carrano <<a href="mailto:j.carrano@fu-berlin.de">j.carrano@fu-berlin.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Baptiste,<br>
<br>
On 11/22/18 12:11 PM, Baptiste Clenet wrote:<br>
> Hi,<br>
> I have looked at mutex.c and thread.c and I've understood that a<br>
> thread with higher priority (it has priority) will unlock the mutex<br>
> even if thread with lower priority has not finished/unlock the mutex?<br>
> Am I right?<br>
<br>
You are referring to a situation in which a thread unlocks a mutex it <br>
did not lock before?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">No. A thread A (high priority) locks a mutex which is locked by thread B (low priority)</div><div dir="auto">And it seems that scheduler stops thread B and make thread A run. </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In that case the mutex is not behaving as such, but rather as a generic<br>
lock, and any thread can unlock it. See <br>
<a href="https://github.com/RIOT-OS/RIOT/issues/9594" rel="noreferrer noreferrer" target="_blank">https://github.com/RIOT-OS/RIOT/issues/9594</a> .<br>
<br>
If you want the mutex to actually behave as a mutex you should ensure <br>
you never have an unlock without a matching lock (i.e. that the only <br>
thread that can unlock a mutex is the one that locked it and thus own <br>
it). RIOT's mutexes do not enforce that, so you must resolve it by <br>
careful usage.<br>
<br>
> Now, in my case, I use UART with ethos (which use a mutex) and what<br>
> happens on my case is:<br>
> * I have thread A (high priority), thread B (low priority)<br>
> * B starts to write on UART an long str<br>
> * A wants to write on UART an lock the mutex (ethos) but because it<br>
> has higher priority, it sends its message over UART until end of str<br>
> * B can continue and finish to send its str<br>
> <br>
<br>
So you are saying that the lower priority "B" thread is being preempted <br>
and it's output interrupted by A's output?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes exactly and this my problem. In my case, main thread with shell is being preempted by one of network stack threads</div><div dir="auto"><br></div><div dir="auto">Let le explain again what I see:</div><div dir="auto">Context: </div><div dir="auto">* two threads: main thread (low prio) with shell and ipv6 thread (high prio)</div><div dir="auto">Sequence:</div><div dir="auto">1. Main thread starts to send a long str by UART via ethos (ethos_send_frame)</div><div dir="auto">2. Main thread locks ethos mutex in ethos_send_frame</div><div dir="auto">3. Ipv6 thread wants to send a str by UART, so ethos_send_frame is called and ipv6 thread tries to locks ethos mutex. </div><div dir="auto"><br></div><div dir="auto">Result: What I see is that main thread str is cut by ipv6 thread. Str seen from UART reception:</div><div dir="auto">[START_STR_MAIN_THREAD][IPV6_THREAD_STR][END_STR_MAIN_THREAD]</div><div dir="auto"><br></div><div dir="auto">4. IMO, ipv6 thread preempts main thread and, I don't really how, manages to access UART device and send its str before main thread can finish to send its str</div><div dir="auto"><br></div><div dir="auto">Result is that main thread str is cut</div><div dir="auto"><br></div><div dir="auto">Please have a look at ethos.c and especially ethos_send_frame() function to better understand what I say.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm not familiar with ethos, but my intuition is that, while it may have <br>
a mutex, it may not be programmed in a way that the UART access is <br>
exclusive too. Exclusive access to UART would not be a good idea as in <br>
cases like yours it opens the door to priority inversions.<br>
<br>
> So I'm wondering why a thread with higher priority should be able to<br>
> unlock a mutex locked by a thread with lower priorty?<br>
> <br>
<br>
Actually any thread can unlock a mutex locked by another thread. What <br>
can never happen is that a thread _locks_ a mutex locked by another <br>
thread. In your mind, replace the word "mutex" with "lock" and things <br>
may become clearer.<br>
<br>
Regards,<br>
<br>
Juan.<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@riot-os.org" target="_blank" rel="noreferrer">devel@riot-os.org</a><br>
<a href="https://lists.riot-os.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">https://lists.riot-os.org/mailman/listinfo/devel</a><br>
</blockquote></div></div></div>