<div dir="auto">I've opened an Issue on github showing how to reproduce:<div dir="auto"><a href="https://github.com/RIOT-OS/RIOT/issues/10495">https://github.com/RIOT-OS/RIOT/issues/10495</a><br></div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr">Le mer. 28 nov. 2018 12:03, Baptiste Clenet <<a href="mailto:bapclenet@gmail.com">bapclenet@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The behavior is only seen when ethos is used:<br>
Checkout my branch: <a href="https://github.com/biboc/RIOT/tree/uart_mutex_thread_pb" rel="noreferrer noreferrer" target="_blank">https://github.com/biboc/RIOT/tree/uart_mutex_thread_pb</a><br>
And run example uart-thread-mutex_pb_BR on samr21-xpro (make flash<br>
BOARD=samr21-xpro)<br>
<br>
See output:<br>
2018-11-28 11:58:50.71 ~~33     `@0909]!UHCP@~~}!main(): This is RIOT!<br>
(Version: 2018.10-RC1-330-gd8cfe-uart_mutex_thread_pb)<br>
2018-11-28 11:58:50.71 ~~}!RIOT border router example application<br>
2018-11-28 11:58:50.72 ~~}!THREAD<br>
2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+<br>
2018-11-28 11:58:50.74 ~~}!THREAD 2-|+2-|+2-|+2-|+THREAD<br>
1_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*1<br>
2018-11-28 11:58:50.75<br>
~~}!2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+<br>
2018-11-28 11:58:50.76 ~~}!THREAD<br>
2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+<br>
<br>
Le jeu. 22 nov. 2018 à 15:44, Baptiste Clenet <<a href="mailto:bapclenet@gmail.com" target="_blank" rel="noreferrer">bapclenet@gmail.com</a>> a écrit :<br>
><br>
> Thanks for your answer.<br>
><br>
> Le jeu. 22 nov. 2018 12:51, Juan Ignacio Carrano <<a href="mailto:j.carrano@fu-berlin.de" target="_blank" rel="noreferrer">j.carrano@fu-berlin.de</a>> a écrit :<br>
>><br>
>> 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>
><br>
><br>
> No. A thread A (high priority) locks a mutex which is locked by thread B (low priority)<br>
> And it seems that scheduler stops thread B and make thread A run.<br>
>><br>
>><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>
><br>
><br>
> Yes exactly and this my problem. In my case, main thread with shell is being preempted by one of network stack threads<br>
><br>
> Let le explain again what I see:<br>
> Context:<br>
> * two threads: main thread (low prio) with shell and ipv6 thread (high prio)<br>
> Sequence:<br>
> 1. Main thread starts to send a long str by UART via ethos (ethos_send_frame)<br>
> 2. Main thread locks ethos mutex in ethos_send_frame<br>
> 3. Ipv6 thread wants to send a str by UART, so ethos_send_frame is called and ipv6 thread tries to locks ethos mutex.<br>
><br>
> Result: What I see is that main thread str is cut by ipv6 thread. Str seen from UART reception:<br>
> [START_STR_MAIN_THREAD][IPV6_THREAD_STR][END_STR_MAIN_THREAD]<br>
><br>
> 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<br>
><br>
> Result is that main thread str is cut<br>
><br>
> Please have a look at ethos.c and especially ethos_send_frame() function to better understand what I say.<br>
><br>
><br>
><br>
><br>
>><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>
<br>
<br>
<br>
-- <br>
Baptiste<br>
</blockquote></div>