Porting Embedded Rapid Prototyper Run-Time Libraries : Structure of the Code : Main Task – Partition and Flow of Control : Entering the WAIT State

Entering the WAIT State

If the system executed the idle step, it is in a stationary condition. Note that the negation of events might yield an active trigger after the idle step. If such negation events are found in the model, a warning message will be issued in the .info file.

At this point, the main task will release the CPU by calling to a system service that will block it from running, until some external stimulus occurs. The external stimulus can be either an event/data change, or a time-out.

In cases where the wait primitive is “blind,” i.e., it is not based on a condition such as a semaphore or event flag, the test whether to enter a wait state or not should be handled carefully, since once the main task blocks itself only external input will wake it. This is the case in Unix, where the pause primitive is “blind” in the sense that it will block the whole process unconditionally. Therefore, the sched_pause procedure, that actually blocks the task, must test and block mutually exclusive to other asynchronous tasks (such as the timer ISR), to prevent a deadlock.

If the wait call is based on an event flag or a semaphore, then the above scenario will not lead to a deadlock, since the wakeup call will release the waiting flag (semaphore) and the wait primitive will simply flow through. This is usually the case in RTOS.