I've opened an Issue on github showing how to reproduce: https://github.com/RIOT-OS/RIOT/issues/10495
Le mer. 28 nov. 2018 12:03, Baptiste Clenet <bapcle...@gmail.com> a écrit : > 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