The behavior is only seen when ethos is used: Checkout my branch: https://github.com/biboc/RIOT/tree/uart_mutex_thread_pb And run example uart-thread-mutex_pb_BR on samr21-xpro (make flash BOARD=samr21-xpro)
See output: 2018-11-28 11:58:50.71 ~~33 `@0909]!UHCP@~~}!main(): This is RIOT! (Version: 2018.10-RC1-330-gd8cfe-uart_mutex_thread_pb) 2018-11-28 11:58:50.71 ~~}!RIOT border router example application 2018-11-28 11:58:50.72 ~~}!THREAD 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-|+ 2018-11-28 11:58:50.74 ~~}!THREAD 2-|+2-|+2-|+2-|+THREAD 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 2018-11-28 11:58:50.75 ~~}!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-|+ 2018-11-28 11:58:50.76 ~~}!THREAD 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-|+ Le jeu. 22 nov. 2018 à 15:44, Baptiste Clenet <bapcle...@gmail.com> a écrit : > > Thanks for your answer. > > Le jeu. 22 nov. 2018 12:51, Juan Ignacio Carrano <j.carr...@fu-berlin.de> a > écrit : >> >> Hi Baptiste, >> >> On 11/22/18 12:11 PM, Baptiste Clenet wrote: >> > Hi, >> > I have looked at mutex.c and thread.c and I've understood that a >> > thread with higher priority (it has priority) will unlock the mutex >> > even if thread with lower priority has not finished/unlock the mutex? >> > Am I right? >> >> You are referring to a situation in which a thread unlocks a mutex it >> did not lock before? > > > No. A thread A (high priority) locks a mutex which is locked by thread B (low > priority) > And it seems that scheduler stops thread B and make thread A run. >> >> >> In that case the mutex is not behaving as such, but rather as a generic >> lock, and any thread can unlock it. See >> https://github.com/RIOT-OS/RIOT/issues/9594 . >> >> If you want the mutex to actually behave as a mutex you should ensure >> you never have an unlock without a matching lock (i.e. that the only >> thread that can unlock a mutex is the one that locked it and thus own >> it). RIOT's mutexes do not enforce that, so you must resolve it by >> careful usage. >> >> > Now, in my case, I use UART with ethos (which use a mutex) and what >> > happens on my case is: >> > * I have thread A (high priority), thread B (low priority) >> > * B starts to write on UART an long str >> > * A wants to write on UART an lock the mutex (ethos) but because it >> > has higher priority, it sends its message over UART until end of str >> > * B can continue and finish to send its str >> > >> >> So you are saying that the lower priority "B" thread is being preempted >> and it's output interrupted by A's output? > > > Yes exactly and this my problem. In my case, main thread with shell is being > preempted by one of network stack threads > > Let le explain again what I see: > Context: > * two threads: main thread (low prio) with shell and ipv6 thread (high prio) > Sequence: > 1. Main thread starts to send a long str by UART via ethos (ethos_send_frame) > 2. Main thread locks ethos mutex in ethos_send_frame > 3. Ipv6 thread wants to send a str by UART, so ethos_send_frame is called and > ipv6 thread tries to locks ethos mutex. > > Result: What I see is that main thread str is cut by ipv6 thread. Str seen > from UART reception: > [START_STR_MAIN_THREAD][IPV6_THREAD_STR][END_STR_MAIN_THREAD] > > 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 > > Result is that main thread str is cut > > Please have a look at ethos.c and especially ethos_send_frame() function to > better understand what I say. > > > > >> >> I'm not familiar with ethos, but my intuition is that, while it may have >> a mutex, it may not be programmed in a way that the UART access is >> exclusive too. Exclusive access to UART would not be a good idea as in >> cases like yours it opens the door to priority inversions. >> >> > So I'm wondering why a thread with higher priority should be able to >> > unlock a mutex locked by a thread with lower priorty? >> > >> >> Actually any thread can unlock a mutex locked by another thread. What >> can never happen is that a thread _locks_ a mutex locked by another >> thread. In your mind, replace the word "mutex" with "lock" and things >> may become clearer. >> >> Regards, >> >> Juan. >> _______________________________________________ >> devel mailing list >> devel@riot-os.org >> https://lists.riot-os.org/mailman/listinfo/devel -- Baptiste _______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
