1. Task status and transition

AliOS Things is a real-time operating system that supports multiple tasks running on a single processor. For a multitasking system, only one task can be running on a single processor at any time, and all other tasks are in a non-running state. So here you can simply think that the task has two states: running and non-running, as shown in Figure 1.

Figure 1 Top-level model of task states and transitions

When the task is in the running state, the processor is used to execute the code of the task; when the task is in the non-running state, its running context is saved and will be resumed when it enters the running state the next time. When the task resumes execution, it will start execution from the instruction to be executed before leaving the running state last time. When and why the task is switched between the non-running state and the running state, it is mainly based on the system's scheduling strategy, system events that can cause scheduling, and specific function calls.

Real-time operating system task scheduling relies on task priority. Tasks with high real-time requirements are given high priority. Once the high-priority tasks are ready, the system will swap out the running low-priority tasks. Then the execution power of the processor is handed over to high-priority tasks. For those tasks that do not need to be executed temporarily and are in a non-running state for some reason, they will only be scheduled for execution again when a specific event occurs. Therefore, the non-running state of the task can be divided into two sub-states: ready and suspended, as shown in Figure 2.

Figure 2 Basic model of task status and transition

As shown in Figure 2, only when the task is in the ready state, can it be scheduled by the system to enter the running state; and the task in the running state can be exited in two ways: suspended or preempted. When the task is completed or cannot continue to run for some reason (such as waiting for a certain period of delay), it enters a state of temporarily stopping operation, that is, the suspended state. When a task enters a suspended state, it releases processor resources to other tasks. Tasks can actively abandon the processor because they complete the corresponding operations or generate signals from their own programs; tasks will also passively abandon processor resources due to other tasks preempted, time expired, or system events are forced out by the system, and tasks give up processor resources. The reason can be seen in Figure 3.

Figure 3 Reasons for task suspension

Note that for tasks that have not been completed and are preempted by other tasks and forcibly abandoned the processor, they will not be suspended but in a ready state, waiting to be scheduled again by the system.

Combined with the analysis of the reasons for the suspension of the above tasks, a general model of the task state can be obtained as shown in Figure 4. The conditions for the task to enter the ready state from the suspended state, including the combination of event, time interval expiration, event and time interval expiration .

Figure 4 General model of task state and transition

2. Realize

The task status reflects the status of tasks in the current system, and the operating system kernel needs to maintain the current status of all tasks. Due to the many conditions and factors that trigger task state switching, different operating systems have different definitions of system task state types and migration changes, as shown in Figure 5, Figure 6, and Figure 7, respectively. FreeRTOS, RT-Thread, Task state diagrams of AliOS Things. They refine the suspended state on the general model of task state, but the definition of sub-classes is different, and the changes in task state transition caused by similar events are also different. .

2.1 、 FreeRTOS

FreeRTOS refines the suspend state in the general model into two states: blocking and suspend. The state in which the task is waiting for an event is called the blocking state. There are two types of events waiting for the task to enter the blocking state:

(1) Time-related events

The expiration of the delay interval or the arrival of absolute time. For example, the task is allowed to be scheduled after a delay of 10ms by calling vTaskDelay().

(2) Synchronization event

Events or interrupts generated by other tasks. For example, the task calls xQueueReceive() to wait for the data to arrive in the queue.

Tasks in the suspended state will no longer be scheduled, and the tasks will only be scheduled when the suspended state is released by other tasks. Tasks that are in the ready state, running state or blocked state can all enter the suspended state by calling vTaskSuspend(). When a task calls vTaskResume() to wake it up, the task enters the ready state.

The newly created task is in the ready state because it does not need to wait for any resources. When the system is scheduled, if there is no higher priority task in the ready state, the task will be scheduled to enter the running state.

Figure 5 FreeRTOS task status and transition

2.2、RT-Thread

RT-Thread introduces two new states on the task state basic model: initial state and closed state. After the task is created, it enters the initial state. The task in the initial state can enter the ready state by calling the rt_thread_startup() function. When the task runs and executes the rt_thread_exit() function or is deleted or destroyed by other tasks calling the rt_thread_delete/detach() function, the task enters the closed state. Tasks in the running state can enter the suspended state by calling functions such as rt_thread_delay(), rt_sem_take(), rt_mutex_take(), rt_mb_recv(), etc.; the thread in the suspended state, if the waiting timeout still fails to obtain resources or due to other The thread releases the resource, then it returns to the ready state.

Figure 6 RT-Thread task status and transition

2.3、AliOS Things

In order to fully describe the state of the task in the system and the difference in conditions that trigger the state transition, AliOS Things adds a task deletion state to the basic model of the above task state and refines the suspended state, which is specifically divided into the suspended state , Sleep state and blocking state, as shown in Figure 7.

Figure 7 AliOS Things task status and transition

(1) The blocking state refers to the waiting state due to waiting for resources, such as calling aos_mutex_lock() to obtain the mutex when the mutex has been locked, calling aos_queue_recv() to obtain the queue data when the queue is empty, calling aos_sem_wait() to wait for the signal When the semaphore count is 0 and the aos_evnet_get() is called to get the event, the event has not occurred yet;

(2) Suspended state is that the task will be unconditionally stopped after it is called by other or itself suspend function aos_task_suspend(). The suspended task can only be restored to the ready state by calling the resume function aos_task_resume() of other tasks. ；

(3) The sleep state is because the task enters a delayed execution state after calling the task sleep function aos_msleep(), until the sleep time reaches the task and is rescheduled to resume operation.

(4) The delete state is a state that is set when the task exit function aos_task_exit() is called or the task delete function aos_task_del() is called because the task is completed.

Compared with RT-Thread and FreeRTOS, AliOS Things gives more flexibility to the state of newly created tasks. When the task is created by calling the aos_task_new() function, the task state is the ready state. If the application does not require the task to be scheduled for execution immediately after creation, you can create the task by calling the aos_task_new_ext() function and setting the parameter autorun to 0. At this time, the task is in a suspended state. When the application requires task execution, you can call The aos_task_resume() function switches the task to the ready state. When the task is in the ready state, when the system is scheduled, the task with the highest priority will gain control of the processor and enter the running state. If there are other higher priority tasks in the ready state at this time, the task will be preempted and put back into the ready state.

AliOS Things allows tasks to be in a combined state: blocking suspended state or dormant suspended state:

(1) When the task is suspended by other tasks in the blocking state, it enters the blocking suspended state. In this state, if the task is restored, it will remain blocked; if the task is unblocked, it will remain suspended.

(2) When the task is suspended by other tasks in the dormant state, it enters the dormant suspended state. In this state, if the task is resumed, it will remain in the dormant state; if the task has expired, it will remain in the suspended state.

Note that although the task in the blocking state in FreeRTOS can be suspended, the task is no longer blocked after being suspended, even if the task waiting for the event does not occur, once the task is resumed, it will enter the ready state. In AliOS Things, the task is waiting for an event to enter the blocking state, and at this time it is suspended by other tasks. The task is still in the blocking state. If the waiting event occurs during this process, the task will be unblocked. Enter the suspended state; if the event does not occur, the task is still in the blocked state after it resumes the state. The advantage of this design is to ensure that the task is unblocked due to the occurrence of a waiting specific event, rather than because the task is suspended and resumed and the waiting state is eliminated. For example, task A and task B access resource M at the same time, because task B gets the mutex first, task A enters the blocking state because it does not get the mutex, then task C suspends task A and then resumes. At this time, task A is still in a blocked state and cannot access resource M, which can guarantee exclusive access to resource M. If the task state switching method of FreeRTOS is adopted, task A will directly enter the ready state after being suspended and resumed. In this way, task A may access resource M before task B has completed the operation, so that the mutex is not mutually exclusive The role of.

3. Example

Here is an application example to illustrate the task state switching process in AliOS Things, as shown in Figure 8:

(1) At time t0, tasks task1 and task2 are created through aos_task_new() and aos_task_new_ext() function calls respectively, after which task1 enters the ready state, and task2 is in the suspended state.

(2) After Task1 is running, call aos_task_resume() at t1 to resume task2, and task2 enters the ready state, then task1 enters the sleep state by calling aos_msleep(), task2 gets the CPU execution right because task1 sleeps, and task2 waits after running The semaphore enters a blocking state.

(3) Task1 is run due to the delay expiration at time t2, and calls aos_task_suspend() to suspend task2, and task2 is in blocking suspension at this time. Then task1 enters the sleep state by calling aos_msleep().

(4) Task1 is run due to the delay expiration at time t3, and calls aos_task_resume() to restore task2. At this time, the state of task2 is blocked. Then task1 enters the sleep state by calling aos_msleep().

(5) Task1 is run due to the delay expiration at time t4, and calls aos_sem_signal() to release the semaphore. At this time, task2 enters the ready state by waiting for the semaphore. After task1 enters sleep again, task2 is run and enters the running state.

Figure 8 AliOS Things task status and switching application example

According to the application example described in Figure 8, write the code as follows:

#include <aos/kernel.h>
static aos_sem_t g_testsync_sem;
static aos_task_t handle_task2 = {NULL};
void task1_entry()
{
    printf("task1 is running!\n");
    printf("task1 resume task2!\n");
    if (0 != aos_task_resume(&handle_task2))
    {
        printf("task1 resume task2 failed!\n");
    }
    printf("task1 start to sleep and release CPU!\n");
    aos_msleep(10000);

    printf("task1 suspend task2!\n");
    if (0 != aos_task_suspend(&handle_task2))
    {
        printf("task1 resume task2 failed!\n");
    }
    printf("task1 start to sleep and release CPU!\n");
    aos_msleep(10000);

    printf("task1 resume task2 again!\n");
    if (0 != aos_task_resume(&handle_task2))
    {
        printf("task1 resume task2 failed!\n");
    }
    printf("task1 start to sleep and release CPU!\n");
    aos_msleep(10000);
    printf("task1 signal a semphone!\n");
    aos_sem_signal(&g_testsync_sem);
    printf("task1 start to sleep and release CPU!\n");
    aos_msleep(10000);
    aos_task_exit(0);
}

void task2_entry()
{
    printf("task2 is running!\n");
    if (0 != aos_sem_wait(&g_testsync_sem, AOS_WAIT_FOREVER))
    {
        printf("task2 wait semphone failed!\n");
    }

    printf("task2 get semphone and is running!\n");
    aos_task_exit(0);
}

int task_test(void)
{
    int retn;

    retn = aos_sem_new(&g_testsync_sem, 0);
    if (retn != 0)
    {
        printf("%s:%d sem new failed, err=%d\n", __func__, __LINE__, retn);
        return -1;
    }
    if (0 != aos_task_new("task1", task1_entry, NULL, 4096))
    {
        aos_sem_free(&g_testsync_sem);
        return -1;
    }

    if (0 != aos_task_new_ext(&handle_task2, "task2", task2_entry, NULL, 4096, 30, 0))
    {
        aos_sem_free(&g_testsync_sem);
        return -1;
    }

    return 0;
}

The running result of the above code is shown in Figure 9.

Figure 9 Application example code running results

In Figure 9, task2 enters the blocking state after running because the unsemaphore count value is 0. At this time, the task status of task2 is "PEND" through the tasklist command, where "PEND" represents the blocking state; then task1 hangs task2 At this time, the task status of task2 viewed at this time is "PEND_SUS", which represents the blocked suspended status; finally task1 resumes task2, and the task status of task2 is found to be "PEND" at this time, indicating the switch between the code running result and the AlisOS Things task status diagram The process is consistent.