Re: [c++-pthreads] thread-safety definition

[Ted Baker <baker@xxxxxxxxxx>]

> 	2.1) "async cancelation": The OS removes the thread from its list of
> tasks to schedule and does nothing to cleanup the thread ressources.
> This is the most extreme useless feature of a thread library. BeOS and
> win32 provide it. POSIX does not provide it.

There has been a push from the POSIX real-time people to add a new
feature that will kill a thread *instantly* (without executing
cleanup handlers).  They are concerned that there must be a
for-certain way of killing a runaway thread.  They also want a
way to do forced reinitialization of objects like mutexes and
condition variables, to recover from such a disaster.

My own first reaction to this was that they are trying to do fault
recovery at the wrong level of granularity. Since threads share
address space, killing a thread without cleanup is very likely
(almost certain?)  to corrupt memory and/or hold resources in a
way that does not permit reliable continued execution of the
threads that share the same address space.  It seems  they should be
doing their fault recovery at the process level.

Unfortunately, in some real-time POSIX OS's the multiple-process
abstraction is not supported, either to keep the OS footprint
small or because there is no virtual memory hardware support.
This leaves no choice but to use only threads for concurrency, and
then take extreme care in coding and in how resources are
allocated, hoping that one can reliably reinitialize the system
state and recreate needed threads after killing off rogue threads.

--Ted

Incidentally, last time I used Linuxthreads it seemed they
implement pthread_kill() in a way that causes an uncaught
signal to kill just one thread (not like POSIX, which requires
killing the whole process).