OSF DCE Application Development Guide--Core Components

Programming with Threads
unpredictable behavior. For example, one thread has a mutex locked, and the state
covered by that mutex is inconsistent while another thread calls the fork( ) routine. In
the child process, the mutex will be in the locked state, and it cannot be unlocked
because only the forking thread exists in the child process. Having the child reinitialize
the mutex is unsatisfactory because this approach does not resolve the question of how to
correct the inconsistent state in the child.
The atfork( ) routine provides a way for threaded applications or libraries to protect
themselves when a fork() occurs. The atfork() routine allows you to set up routines that
will run at the following times:
Prior to the fork() in the parent process
After the fork( ) in the child process
After the fork( ) in the parent process
Within these routines, you can ensure that all mutexes are locked prior to the fork( ) and
that they are unlocked after the fork( ), thereby protecting any data or resources
associated with the mutexes. You can register any number of sets of atfork( ) routines;
that is, any number of libraries or user programs can set up atfork() routines and they
will all execute at fork( ) time.
Note: Using the atfork( ) routine can potentially cause a deadlock if two
applications or libraries call into one another using calls that require
locking. Specifically, when these component’s routines use the atfork( )
routine to run prior to the fork in the parent process, a deadlock may occur
when these routines are executing.
8.1.1.4 Using the Jacketed System Calls
You do not have to rename your system calls to take advantage of the jacket routines.
Macros put the jacket routines into place when you compile your program; these macros
rename the jacketed system calls to the name of the DCE Threads jacket routine. Thus, a
reference to the DCE Threads jacket routine is compiled into your code instead of a
reference to the system call. When the code is executed, it calls the jacket routine,
which then calls the system on your code’s behalf.
If you do not wish to use any of the jacket routines, you can add the following line to
your program before any of the thread header files:
#define _CMA_NOWRAPPERS_
By adding this definition, you prevent the jacket routines from being substituted for the
real routines.
If you wish to use most of the jackets but do not wish to use a specific jacket, you can
undefine a specific jacket by adding the following directive after the thread header files:
#undef routine_name
For example, to not use the fork jacket, you can add the following:
124245 Tandem Computers Incorporated 83