1
0
mirror of https://github.com/RIOT-OS/RIOT.git synced 2024-12-29 04:50:03 +01:00
RIOT/tests/thread_priority_inversion
Gerson Fernando Budke 4a9f0efb6d boards: introduce atmega328p-xplained-mini
Add ATmega328P Xplained Mini board.  The board is an official
development kit from MCHP based on the Arduino UNO, reduced
hardware, with a xplainedmini debugger and CDC ACM serial
converter.

Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
2021-03-27 14:10:19 -03:00
..
main.c tests/thread_priority_inversion: convert to xtimer_msleep() 2020-11-05 11:34:50 +01:00
Makefile tests: BOARD_INSUFFICIENT_MEMORY -> Makefile.ci 2019-10-17 15:11:59 +02:00
Makefile.ci boards: introduce atmega328p-xplained-mini 2021-03-27 14:10:19 -03:00
README.md tests/thread_priority_inversion: fix typos 2019-11-23 22:39:37 +01:00

thread_priority_inversion test application

This application uses three threads for demonstrating the priority inversion problem. In theory, the highest priority thread (t_high) should be scheduled periodically and produce some output:

2017-07-17 17:00:29,337 - INFO # t_high: got resource.
...
2017-07-17 17:00:30,343 - INFO # t_high: freeing resource...

During this phase of 1s, t_high lockes the mutex res_mtx which represents a shared resource. After unlocking the mutex, t_high waits 1s before restaring its cycle again.

A low priority thread t_low is doing the same. Since both threads sharing the same resource res_mtx, they have to wait for each other until the mutex is unlocked. On startup, t_low starts immediately, while t_high waits 0.5s before so that t_low allocates the resource first. Together, the output looks like this:

2017-07-17 17:00:28,339 - INFO # t_low: allocating resource...
2017-07-17 17:00:28,339 - INFO # t_low: got resource.
2017-07-17 17:00:28,340 - INFO # t_high: allocating resource...
2017-07-17 17:00:29,337 - INFO # t_low: freeing resource...
2017-07-17 17:00:29,337 - INFO # t_high: got resource.
2017-07-17 17:00:29,338 - INFO # t_low: freed resource.
2017-07-17 17:00:30,343 - INFO # t_high: freeing resource...
2017-07-17 17:00:30,344 - INFO # t_high: freed resource.
2017-07-17 17:00:30,345 - INFO # t_low: allocating resource...
2017-07-17 17:00:30,346 - INFO # t_low: got resource.
...

After 3s, a third thread with medium priority (t_mid) is started. This thread does not touch res_mtx, but it runs an infinite loop without leaving some CPU time to lower priority tasks. This prevents t_low from freeing the resource and thus, t_high from running (Priority Inversion). In this situation, the test program output stops with the following lines:

2017-07-17 17:00:31,335 - INFO # t_mid: doing some stupid stuff...
2017-07-17 17:00:31,340 - INFO # t_high: allocating resource...

If the scheduler contains a mechanism for handling this problem, the program should continue with output from t_high.