About Thread_Cancel

Gedare Bloom gedare at rtems.org
Wed Feb 24 16:49:02 UTC 2021

On Wed, Feb 24, 2021 at 12:54 AM Richi Dubey <richidubey at gmail.com> wrote:
> Hi,
> Can someone please give a brief overview of what these three lines aim to achieve:
>   } else if ( _Thread_Is_life_change_allowed( previous ) ) {
>     _Thread_Add_life_change_request( the_thread );
>     _Thread_State_release( the_thread, &lock_context );
>     _Thread_Finalize_life_change( the_thread, priority );
> 492 threadrestart.c
> I am asking because in line 92 of sp02, this _Thread_Cancel function is called, and because of _Thread_Add_life_change_request( the_thread ) ->_Thread_Set_state_locked -> _Scheduler_Block is called and because of _Thread_Finalize_life_change->_Thread_Remove_life_change_request->_Thread_Clear_state_locked->_Scheduler_Unblock is called, which is contradictory.
What is the contradiction? You shouldn't have a blocked thread in a
queue when you want to delete it. The thread needs to be in some kind
of "quiescent" state.

Thread cancellation and end-of-life considerations are tricky. Maybe
your scheduler has some invalid assumptions about how threads

The API-level requirements derive from two directions:


The low-level detailed implementation is probably not so
well-documented. You might be able to find some clues in the doxygen.
Otherwise you probably have to keep working your way through the code
like you have been.

> Thanks,
> Richi.
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

More information about the devel mailing list