using a thread’s own task handle

Richard Barry et al In a previous release, the following code was placed in VTaskDelete() ___/* Ensure a yield is performed if the current task is being ___deleted. */ ___if( pxTaskToDelete == pxCurrentTCB ) ___{ ___pxTaskToDelete = NULL; ___} This ensures that a task can properly delete itself using its own task handle rather than NULL. I thought similar code was also added to vTaskPrioritySet() although so far I have been unable to pin this down. Maybe I had added that myself. But the bottom line is that such code is needed. In the current version, if a task drops its own priority (using its task handle rather than NULL) below another ready task, the other ready task will not be properly scheduled to run (until the next re-scheduling for some other reason). Glen

using a thread’s own task handle

Looking at the history, it was also put into vTaskSuspend(), but not vTaskPrioritySet().  I have just added it in and will check in the changes very shortly. Can you see anywhere else it should be added before I check it in?  I think that’s it. Regards.

using a thread’s own task handle

I think maybe the following in vTaskResume() needs should exclude the current task handle as well as NULL. if( pxTCB != NULL ) {

using a thread’s own task handle

>if( pxTCB != NULL ) >{ I have added the second check here: if( ( pxTCB != NULL ) && ( pxTCB != pxCurrentTCB ) ) { but arguably both could be removed as attempting to resume yourself (using either parameter) would be very odd. Changes now checked in. Regards.

using a thread’s own task handle

Yes, that’s why I was somewhat uncertain about the change to the resume function – however, SafeRTOS needs it, I presume.