Murdock results

✔️ PASSED

149a26e tests/core/thread_msg: lower thread priority for consistent output order

Artifacts

• Documentation preview

OK, I think I can explain the behavior: The threads are created with THREAD_CREATE_WOUT_YIELD, so the main thread should continue and the threads should only ever get started when the main thread yields or blocks for other reasons.

If stdio is primitive, e.g. no DMA and actively feeding data into an UART peripheral, the main thread will be busy until the msg_receive() is called, which is the first point in time it will block. Only then the scheduler is run and the others threads get scheduled.

If however stdio is fancy (e.g. UART with DMA or USB CDC ACM), the stdio access will block and the other threads get run before the printing is complete.

I think we should also drop the THREAD_CREATE_WOUT_YIELD, so that the behavior is less confusing.

Thanks, that at least explains the difference between both tested boards. However, I still don't understand why changing the thread priority then fixes the order: If the main thread is busy waiting for fancy stdio, the other two threads would already be runnable and could start executing right away, too.

Maybe the explanation is actually that the fancy stdio incurs some interrupts which trigger a context switch even before the main thread blocking for stdout as per the documentation?

Purely for optimization. Any other context switch (i.e. an interrupt) can still start the thread at any time!

Maybe the explanation is actually that the fancy stdio incurs some interrupts which trigger a context switch even before the main thread blocking for stdout as per the documentation?

E.g. for UART with DMA they will cause IRQs, but I do believe that at this point the higher prio threads will already be running anyway. My mental model is for UART using DMA is:

1. Enable an IRQ on TX completion
2. Set up the DMA transfer to the peripheral and the peripheral to send out the data from DMA
3. Trigger the transaction
4. block (e.g. mutex_lock() on a locked mutex) --> Scheduling happens here, higher prio thread get run
5. from TX complete ISR: unblock the thread (e.g. mutex_unlock())

In any case, relying on THREAD_CREATE_WOUT_YIELD for ordering is not a reliable thing to do. But if we create the threads at a lower priority than the main thread, thread_create() will not run them anyway, regardless of THREAD_CREATE_WOUT_YIELD. That is why IMHO the use of the THREAD_CREATE_WOUT_YIELD is confusing when creating threads with a lower priority than the running one.

I think we should also drop the THREAD_CREATE_WOUT_YIELD, so that the behavior is less confusing.

Okay, done, and directly squashed.

Thanks!