1290_ Implementation analysis of prvtaskistasksuspended() interface in FreeRTOS

All learning summary ： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)

I just finished analyzing the pending operation of the task , Next, analyze whether the task is a query interface implementation in suspended state . commonly , The interface implementation of this query class is always simpler .

The interface also needs to be configured with a macro definition enable before it can take effect , This is similar to the previous task suspending interface implementation . Next , First, make sure that the incoming task handle is valid .

If the task handle is valid , Then you need to check whether the task is in the suspended task list . If not , Then the query will directly get the result , This task is not suspended . otherwise , Further judgment is needed . That means , stay FreeRTOS The suspended task list in may be used in many functions , This leads to the reuse of linked lists . natural , Sometimes adding some categories to the linked list can make processing easier , But similar processing cannot be merged . therefore , The implemented kernel should be more lightweight .

If the task is in the linked list of suspended tasks , The reason for the suspension may also be the suspension caused by the event . such , Just judge whether the event caused the suspension , If not , The reason why this task is in the suspended task list is the operation of suspended tasks . such , Task is suspended .

Compared with the previous pending operation , The operation of judging whether the task is suspended is indeed simpler . The main reason has also been analyzed before , Similar attribute queries generally do not change various states, so they do not trigger task scheduling . The interface of the modified class is different , Priority and other key attributes may be involved , Task scheduling may be triggered at any time , Therefore, the complexity will be higher .