About Thread_Cancel

[Gedare Bloom]

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
terminate?

The API-level requirements derive from two directions:
https://docs.rtems.org/branches/master/c-user/scheduling-concepts/background.html#task-state-transitions

https://docs.rtems.org/branches/master/posix-users/thread_cancellation.html

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