How does the scheduler mark a thread as critical?
See the next answer.
How does the thread scheduler know that a thread is critical?
QNX Neutrino maintains a data block, the thread_entry, representing the state of each thread. It contains three state bits for controlling the critical threads that indicate whether or not the thread is:
These state bits are turned on as follows:
| Always allowed | When the user calls SchedCtl() with the SCHED_APS_MARK_CRITICAL command on that thread. |
|---|---|
| Until blocked | When the thread receives an event from an interrupt handler, a message from another thread marked either always allowed to run critical, or allow critical until it blocks an event, on which the user has previously called the macro, SIGEV_MAKE_CRITICAL() |
| Currently running as critical | When the scheduler algorithm decides that thread would not have been eligible to run if it hadn't been allowed to run as critical. |
Do critical threads expose security?
No.
You can set your own thread to be critical, or receive a critically tagged event or message. This way, the thread gets the property of the allowed to run critical flag. You must configure the partition with a nonzero critical budget to:
Setting a nonzero critical budget on a partition is controlled. In order to set a nonzero critical budget a target partition in the recommended scheduler partition security settings, a process must have the PROCMGR_AID_APS_ROOT ability enabled, and the process must be running in the parent partition.
When does the scheduler check for bankruptcy?
To save time, the thread scheduler only polls partitions for bankruptcy only on each clock tick (rather than every scheduling operation). So typically, bankruptcy is detected one millisecond (or clock period) after a partition's critical budget has been exhausted.
How does the scheduler detect bankruptcy?
QNX Neutrino compares the total critical time (over the last averaging window) to the partition's configured maximum critical time budget. Each partition maintains a separate rotating window for tracking critical time usage. The history window for this critical time identifies, for each millisecond of the last 100 milliseconds, which part of the total CPU time was considered to be critical time.