OSF DCE Application Development Guide--Introduction and Style Guide

Threads
*global_var = value;
}
/* The following routine returns the thread-specific value ... */
mytype read_global()
{
mytype *global_var;
/* Note the extra indirection; pthread_getspecific() returns */
/* the address of the thread’s private instance of the */
/* storage... */
pthread_getspecific(key, (pthread_addr_t*)&global_var);
return (*global_var);
}
2.3.3 Canceling Threads
In order to program correctly for cancels, applications must be aware of the precise
semantics of cancels in a DCE threads environment. The DCE threads package provides
for per thread cancellation. Thread cancellation allows a thread to attempt to terminate a
thread in the same process in an orderly manner. The basic model is that a cancel is
generated for a thread at an unpredictable time as a result of some external event
(typically, another thread calling pthread_cancel()). Whether and when the canceled
thread acts on a generated cancel depends on the the thread’s cancelability state, which
may be one of the following:
disabled No cancellation takes place.
deferred Cancellation is deferred to cancellation points.
asynchronous Cancellation may occur at any time.
The default action for DCE threads on cancellation is that the thread calls any cancel
cleanup routines that have been established and then terminates. In DCE threads a
canceled thread receives a cancel as an exception, so a thread may establish a nondefault
action by providing an exception handler.
However, this behavior is not recommended for two reasons. First, the exception
handling mechanism is not itself portable. Second, the cancel mechanism is intended to
provide for orderly thread termination. It is not designed as a generalized thread
synchronization mechanism. (There is, for example, only one kind of cancel.) Threads
should use condition variables for this purpose. (For the same reason, the use of
pthread_signal_to_cancel_np( ) is not recommended.)
124246 Tandem Computers Incorporated 2−9