This is to somehow correct the statement that I made in the previous post, "Scheduler in ThreadX": "The scheduler in ThreadX is relatively simple."
No, it is not that simple.
Scheduling of TheadX is not all happened in tx_thread_schedule, which has been described in the previous post. The truth is, in most cases the scheduling occurs outside of tx_thread_schedule. Whenever the system core services:
are invoked, the threads running in the system will be scheduled.
This article will try to share some insight of the system resume service.
Who will use the system resume service for scheduling threads? The figure below shows the clients of the service.
The clients are from services like:
- thread operation
- message queue
- byte/block pool operation
- event flags
Almost all aspects of the system! Anytime when the next ready thread is to be run, the System Resume Service will be called.
Let's take a look closer to what the service does to resume a thread.
First the status of the thread to be resumed will be inspected. If the thread is OK then it will be set to READY state and added to the corresponding priority list.
And then the service will check if the thread could be put into execution. There could be:
- threads that are in the same priority list waiting for execution. In the FIFO priority list, these threads are in the front of the newly added one, which will have to wait for its turn.
- threads that are READY and with higher priorities. In this case the higher-priority-threads will get executed first. The thread we would like to resume will also need to wait for these threads.
At last, the service completes its job, and will pass the bucket to the scheduler, in which the READY thread at the head of the highest priority list will be resumed and executed. This has been covered in Scheduler in ThreadX.
The aforementioned "FIFO priority list", is the key to the priority based scheduling in ThreadX. Together with the list, there is a 32-bit map (when there are 32 priorities)
The bits in the map are indicators of each corresponding priority lists: when it is set, there are some threads ready in the mapped priority thread.
In the example above, there are threads ready in the priority 1 and 5 lists. From the scheduler's perspective, to schedule a next thread is to simply locate the most significant bit set in the map and pick the thread at the head of the mapped priority list.