[c++-pthreads] thread-safety definition

[Dave Butenhof]

Mathieu Lacage wrote:

>Definition "cancelation"
>------------------------
>All OSes provide a mean to stop the execution flow of a thread either
>from the inside of the thread or from the outside.
>
>1) "inside cancelation": This is basically ExitThread (win32 name). It
>exists on all the platforms which support a form of threads or another I
>know of. It semantics vary a lot from one platform to the other
>unfortunatly. On win32, it will not invoke any thread-specific cleanup
>handlers (neither C++ exceptions nor SEH are involved). On BeOS
>(exit_thread), it will behave just like on windows. On POSIX
>(pthread_exit) systems, it will invoke the thread-specific cancelation
>handlers.
>  
>
The term "cancellation" seems heavy here. This is just a voluntary 
termination. But, yes, there are similar properties -- certainly from 
the point of view of the rest of the frames on the call stack at the time.

>2) "outside cancelation": There are two kinds of "outside cancelation":
>
>	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.
>  
>
I'd call this "abort", largely because there was at one time a proposal 
for a POSIX function to achieve this, which would have been called 
pthread_abort().

POSIX already defines "async cancel", as a mode where posting a cancel 
to a thread will cause the cancellation to be delivered at any arbitrary 
time supported by the OS and hardware. (Usually on the next clock tick, 
though that's a "common implementation" rather than any rule or even 
recommendation.)

>	2.2) "defered cancelation": I know of only POSIX to implement this. The
>canceled flag for the target thread is set and the thread cancelation
>handlers are invoked whenever the thread reaches a cancelation point
>(that is, it calls one of a set of specific library functions).
>  
>
"Cancellation" (both deferred and async) come from the Digital "CMA" 
architecture (where it was called "alert"). The CMA concept derives from 
a less structured (but fundamentally similar) capability in the SRC 
research labs' Topaz thread package.

>Definition "Posix thread-safety":
>---------------------------------
>A library is "posix thread-safe" if it is thread-safe and
>defered-cancelation-safe.
>  
>
I wouldn't tack cancel-safety onto thread-safety so intimately, although 
I would agree that it's pointless to declare a general library function 
"thread safe under POSIX" unless it also supports deferred cancellation. 
(Async cancel is an oddity; there are, and should be, very few 
async-cancel-safe functions. Async-cancel regions of code cannot 
accomodate resource acquisition or release of any sort, as the recovery 
code is generally unable to determine the state of the resource.)

Nevertheless, it's quite reasonable to write a "thread-safe" special 
purpose application routine that doesn't deal with cancellation simply 
because the designer KNOWS that a thread running that code cannot be 
cancelled. One might even make this choice within in a general purpose 
library in some cases -- say, for a daemon thread that could never run 
application code nor be identified to the application, and that 
therefore cannot be cancelled.

-- 
/--------------------[ David.Butenhof at hp.com ]--------------------\
| Hewlett-Packard Company       Tru64 UNIX & VMS Thread Architect |
|     My book: http://www.awl.com/cseng/titles/0-201-63392-2/     |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/