On Wed, Feb 24, 2021 at 12:54 AM Richi Dubey <richidu...@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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
