TP5 : Threads with equal priority

Hi,

I tried priority 6 and 8 for “my thread” and check behavior as explained in TP5.

But I also tried to set priority level to 7, to have equal priority with main(). I was expecting that the sheduler would share computational time between the two threads (as it is on an computer). That would mean having the hello world message AND shell open.

But I could only have shell open and no message from “my thread”… So “my thread” seems to be asleep or waiting main() has finished.

Am I missing something ??

Thanks for the MOOC !
Marc

Yes, it seems to the case. Note that in general it’s not a good idea to have several threads with the same priority. The behavior can be unpredictable.

I don’t know much about OS (and I learn a lot in this mooc). But I had in mind that multi-tasking was actually the ability of the OS to share resources (memory and CPU time) between processes.

But I understood that in RIOT, the process with the highest priority will take all the CPU time. So if different processes must have different priority, it will act as a mono-task processor, I’m wrong ?

Looking at “top” on my linux, there are many processes with the same priority (most of them are 20) and in a user point of view, they seems to share CPU time as I can listen music while editing latex files and while my mail box is automatically checked, etc… Is it different in RIOT ?

In a IoT point of view, if a service thread manage ethernet (as an example), it must be able to work concurrently with the main application, no ?

Thanks for your explanation as I probably misunderstand several points.

In general, microcontrollers one have a single computing unit, so only a single thread is active at a time.

if a service thread manage ethernet (as an example), it must be able to work concurrently with the main application, no ?

The scheduling of tasks is event based, e.g tickless, which means there’s no background running loops that checks if a thread has something to do. In RIOT, the concept, is to schedule a thread based on a hardware interrupt. In the networking case, the once a paquet is received by the transceiver, an interrupt is raised, the interrupt subroutine preempt any running thread, and schedule the thread responsible in processing the received paquet. Once done and the receiving switch back to a waiting state and the scheduler can re-schedule the thread that was initially running, without loosing its previous internal state.