In many embedded systems the various threads are allocated statically,
created during initialization, and never need to terminate. This
avoids any need for dynamic memory allocation or other resource
management facilities. However if a given application does have a
requirement that some threads be created dynamically, must terminate,
and their resources such as the stack be reclaimed, then the kernel
provides the functions cyg_thread_exit,
cyg_thread_kill, and
cyg_thread_delete.
cyg_thread_exit allows a thread to terminate
itself, thus ensuring that it will not be run again by the scheduler.
However the cyg_thread data structure passed
to cyg_thread_create remains in use, and the
handle returned by cyg_thread_create remains
valid. This allows other threads to perform certain operations on the
terminated thread, for example to determine its stack usage via
cyg_thread_measure_stack_usage. When the handle
and cyg_thread structure are no longer
required, cyg_thread_delete should be called to
release these resources. If the stack was dynamically allocated then
this should not be freed until after the call to
cyg_thread_delete.
Alternatively, one thread may use cyg_thread_kill
on another This has much the same effect as the affected thread
calling cyg_thread_exit. However killing a thread
is generally rather dangerous because no attempt is made to unlock any
synchronization primitives currently owned by that thread or release
any other resources that thread may have claimed. Therefore use of
this function should be avoided, and
cyg_thread_exit is preferred.
cyg_thread_kill cannot be used by a thread to
kill itself.
cyg_thread_delete should be used on a thread
after it has exited and is no longer required. After this call the
thread handle is no longer valid, and both the
cyg_thread structure and the thread stack can
be re-used or freed. If cyg_thread_delete is
invoked on a thread that is still running then there is an implicit
call to cyg_thread_kill. This function returns
true if the delete was successful, and
false if the delete did not happen. The delete
may not happen for example if the thread being destroyed is a lower
priority thread than the running thread, and will thus not wake up
in order to exit until it is rescheduled.