Delete kernel created task in vTaskEndScheduler #962
Conversation
|
Failure with the following unit test. Once unit test is fixed. This PR will be ready for review.
|
* The last application still need to be deleted by application. It has to be deleted after scheduler stopped.
…om/chinglee-iot/FreeRTOS-Kernel into update-end-scheduler-free-resource
chinglee-iot
changed the title
chinglee-iot
changed the title
|
This branch is working, however there are still leaks due to the lack of ability to join. I think whats happening is something like:
I'd like graceful shutdown, vs. having the management thread vTaskDelete() the sub-thread. What I'd do on posix:
Thoughts on adding join functionality to close this opening or should I be giving up on graceful shutdown and killing the thread directly from the management thread? |
@cmorganBE The question you have is about how to gracefully delete application created tasks. FreeRTOS doesn't have pthread_join like function. FreeRTOS inter-task communication can be used to synchronize the management task and sub-task X in your example. For example, we can make use of a event queue to synchronize sub-task and management task in your example. Sub-task X sends an event to notify management task that it is ready to be deleted then blocks itself. Once management task receives this event, it can delete the sub-task X. There may have more than one solution to this question depends on different requirements. pthread_join like function is also a new feature to FreeRTOS and we should discuss this feature with you in FreeRTOS forum. I would like to suggest we move the discussion there. We can also have the suggestion or experience share from the community. |
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
You are right that FreeRTOS does not support POSIX like join functionality currently. Till something like join is implemented in the kernel, we can achieve the same in the application by doing something like the following: #define TASK_X_BIT ( 1 << 0 )
#define TASK_Y_BIT ( 1 << 1 )
#define ALL_TASKS ( TASK_X_BIT | TASK_Y_BIT )
EventGroupHandle_t xTaskTrackingGroup;
void vSubTaskX( void *pvParams )
{
for( ;; )
{
/* TaskX code. */
}
/* Inform the management task. */
xEventGroupSetBits( xTaskTrackingGroup, TASK_X_BIT );
vTaskSuspend( NULL );
}
void vSubTaskY( void *pvParams )
{
for( ;; )
{
/* TaskY code. */
}
/* Inform the management task. */
xEventGroupSetBits( xTaskTrackingGroup, TASK_Y_BIT );
vTaskSuspend( NULL );
}
void vManagementTask( void *pvParams )
{
xEventGroupWaitBits( xTaskTrackingGroup,
ALL_TASKS,
pdFALSE,
pdTRUE, /* Wait for all the tasks to finish. */
portMAX_DELAY );
/* Delete all the sub tasks. */
vTaskDelete( xSubTaskXhandle );
vTaskDelete( xSubTaskYhandle );
vTaskEndScheduler();
/* The task code here should not be run. */
configASSERT( pdFASLE );
}
int main( void )
{
xTaskTrackingGroup = xEventGroupCreate();
/* Creating management and subtasks. */
/* Start the scheduler. */
vTaskStartScheduler();
/* Assuming the application continue to execute from here after
* vTaskEndScheduler is called . */
/* The management task can now be safely deleted here. */
vTaskDelete( xManagementTaskHandle );
}@cmorganBE What do you think? |
|
Delete kernel created task in vTaskEndScheduler
Description
This PR addresses the discussion in #956 - Valgrind detects TCBs and stacks of deleted tasks are not freed after the scheduler stops.
There are 2 type of kernel objects -
In order to keep the resource ownership clear, the application should delete the kernel objects that it creates and the kernel should delete the ones it creates. In line with that, timer task and idle tasks are now deleted in
vTaskEndScheduler().vTaskEndScheduler()must be called from a task and we cannot delete that task fromvTaskEndScheduler(). The application is responsible for deleting the task that callsvTaskEndScheduler()after stopping the scheduler.Example to delete the last running task
In this PR
vTaskDelete()to delete a task directly when scheduler is stopped instead of putting it on the xTasksWaitingTermination list.vTaskEndScheduler().vTaskEndScheduler().Test Steps
Test with posix port and test cases contributed by @cmorganBE. The test cases is updated in this branch
valgrind test result shows no memory leakage after scheduler stops or restarting scheduler
The test
Checklist:
Related Issue
#956
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.