Chapter 13.

Threads

13.1 AIX Kernel Support of Pthreads

Today, many applications have requirements for multiple threads of control.
Multiple threads of control allow an application to overlap operations such as
reading from a terminal and writing to a disk file. This also allows an application
to service requests from multiple users at the same time. Multiple threads of
control within a single process are required by application developers to be able
to provide these capabilities without the overhead of multiple processes. True
concurrence for multiple threads of control is provided by multi-processor
hardware. Multiple threads of control within a single process allow application
developers to exploit this hardware. To meet these needs, new features have
been provided in AIX Version 4.1.

The AIX Version 4.1 kernel now supports multiple threads of control within a
single process. An application can use this to bypass classical Inter-Process
Communications (IPC). That is, data can be shared between the various threads
of control using normal process storage, and access to this data is coordinated
using library routines, thus removing the overhead of IPC associated with shared
memory and semaphores.

AIX Version 4.1 provides an implementation of libpthreads to allow the

application developer to develop portable multi-threaded applications. The
libpthreads library has been written to the POSIX 1003.4a Draft 7 specification1 .
libpthreads is a linkable user library that provides user space threads services
to an application.

There is also a set of kernel services provided to the writer of kernel extensions
for creating and managing threads. New locking services are also provided to
assist the kernel developer working in the multi-processor environment. Now a
kernel developer can write software so it will run on both uni-processor and
multi-processor machines.

13.2 Terms
The threads programming environment has new terminology that needs to be
understood.
Multi-Threaded A program that has multiple threads of control.
This can run in user or kernel space.
Multi-Processor A hardware system that has multiple processors -
multiple units executing instructions.
Symmetrical Multi-Processor A multi-processor system in which the capabilities
and configuration of each processor is (nearly)
identical. This means that the various processors
run a single copy of software, and share and

1 POSIX 1003.4a Draft 7 is not an approved standard. It is IBM′s intention to track evolving standards activity in this area.

 Copyright IBM Corp. 1994 221

 coordinate access to memory and I/O devices. All
resources outside the processor are shared.
Thread Safe A program is thread safe when multiple threads in
a process can be running that program
successfully without data corruption. A library is
thread safe when multiple threads can be running
a routine in that library without data corruption.
Typically, thread-safe routines implement locking
schemes to prevent data from being accessed by
multiple threads at the same time.
Kernel Thread This is a thread of control that is running in kernel
space.
User Thread This is a thread of control running in user space.
The user thread is attached to a kernel thread to
gain access to system services.
MP Safe A program, such as a kernel extension or a device
driver, is said to be multi-processor safe when it
can support multiple processors running that
program successfully without data corruption.
Typically, this is done through a code locking
method. That is, a single lock is used by the
program to ensure that only one instance of the
program is actually running at a time.
MP Efficient A program is said to be multi-processor efficient
when it is written so that it can run on multiple
processors simultaneously. The software may
have to implement a data locking protocol to
protect critical data from being corrupted when two
or more processors attempt to simultaneously
update the data.

The AIX Version 4.1 threads support is based on the OSF/1 libpthreads
implementation. It supports what is referred to as a 1:1 model. This means that
for every thread visible to an application, there is a corresponding kernel thread.
In contrast, the DCE pthreads (POSIX threads) package, available on earlier
releases of AIX, supported a N:1 model. This means that all the threads visible
to a process were mapped onto a single kernel thread. Architecturally, it is
possible to have a M:N libpthreads model, where (“M”) user threads are
multiplexed on a number (“N”) of kernel threads. However, this is not supported
by AIX Version 4.1.

13.3 Threads
In an AIX process, there is one stream of instructions that is in control of the
process at one time. In a multi-threaded process, the process starts out with
one stream of instructions and may later create other instruction streams, called
threads, to do tasks. This is very much like one process forking another
process. There are, however, two main differences between forking a child
process and creating a thread within the current process:

222 All About AIX Version 4.1

 1. fork creates a hierarchical relationship; there are parent and child
processes, and every child has a parent. With multiple threads within a
process, all the threads are peers.
2. Threads within a process share the same address space. Parent and child
processes inhabit entirely different address spaces, and must use system
IPC facilities (such as pipes or shared memory) to communicate.

Facilities are provided to the programmer to do many of the same things that
can be done with processes. These facilities include calls for thread creation,
termination, synchronizing, communication, error recovery, and management.
When a thread is running in user space, it can make system calls just like in a
simple process. Thus, the programmer has the same level of control over how
the threads behave and what services they request of the system within the
process that they have always had for individual processes.

In a multi-threaded process, there is the concept of user threads that run in user
space. Each such user thread is associated with a kernel thread that runs in
kernel space (the “1:1 model” mentioned above). It is the kernel thread that is
managed by the scheduler and handles all of the kernel requirements of the user
thread. A kernel thread, however, may be associated with a user thread to do
user work or it may be unassociated with any user thread and running as a
kernel thread (that is, a kproc or a kernel extension).

Kernel threads appear and behave in AIX Version 4.1 much like kernel
processes did in AIX Version 3.2. It is in user space that the differences between
threads and processes become apparent.

13.4 Multi-Threaded Processes

What a multi-threaded process looks like is detailed in the chart below. The
process shares most data between the threads, except that each thread has its
own copy of the registers, some kernel thread specific data and a private stack.
Therefore, data can be passed between threads via global variables.

There is an important consequence of this that must be kept in mind in

programming in a threaded environment. A traditional UNIX process, if
incorrectly coded, can harm only itself. Except for such things as explicitly
shared memory segments, it cannot directly affect other processes. However,
since all threads in a process share the same address space, an incorrectly
coded program running on one thread in a process could damage the stack and
data areas associated with other threads in that process.

Chapter 13. Threads 223

Figure 16. Thread/Process Relationship

There is some kernel data that is shared between the threads, but the kernel
also maintains thread specific data. Process-related kernel data has been
stored in the proc and user structures. In AIX Version 4.1, these control blocks
have been broken up in process- and thread-specific structures. The user and
proc structures now contain only data that is maintained at the process level.
There is now a thread structure that contains thread-specific data that was
formerly in the proc structure. There is also a uthread structure that contains
thread specific data that used to be in the user structure. The next chart shows
these new control blocks and some sample fields.

224 All About AIX Version 4.1

Figure 17. Thread K e r n e l Structures

In AIX Version 3.2, the kernel maintained data and scheduled and managed
processes. In AIX Version 4.1, all of these functions need to be performed on
both processes and threads. The thread is now the unit of work that is managed
by the scheduler. Each kernel thread is dispatched individually. Some functions,
however, still operate on the process level. These functions affect all threads
within a process. A good example is setting the nice value for a process. That
nice value applies to all threads for the process. Another is exit, which
terminates all threads in a process.

So in AIX Version 4.1, while most operations are now performed on threads,
there are still functions that operate at the process level, and affect all threads in
the process. This is done for compatibility and practicality: in the case where
there is only a single thread in the process, these operations function as before.

Chapter 13. Threads 225

13.5 Thread Architecture
In AIX Version 4.1, the implementation of threads is 1:1. This means that for
every user space thread there will be one kernel space thread to support it.

Figure 18. Thread Architecture 1:1

In this implementation, a user thread is permanently bound to the kernel thread

that supports it when it is created. Architecturally, this type of implementation
produces user threads that are said to be system scope threads . All system
scope threads contend with each other for resources as processes did on AIX
Version 3.2. This implementation behaves as though the your process has
multiple processes built inside.

13.5.1 Threads Scheduling

In AIX Version 3.2, the scheduler dispatched processes. In AIX Version 4.1, the
scheduler dispatches threads (threads are the dispatchable unit for the
scheduler).

226 All About AIX Version 4.1

Each thread created has its own priority, just like a process in AIX Version 3.2.
A thread can have a priority between 0 and 127. Unlike processes, however,
each thread can have its own scheduling algorithm.

There are now three scheduling algorithms that can be selected when creating a
thread.
SCHED_RR This is a round robin scheduling mechanism. The thread is time
sliced at a fixed priority.
SCHED_RR is similar to creating a fixed-priority, real-time
process. The thread must have root authority to be able to use
this scheduling mechanism.
SCHED_FIFO This is a non-preemptive scheduling mechanism. A thread
created with SCHED_FIFO will run at a fixed priority and will not
be timesliced. It will be allowed to run on a processor until it
voluntarily relinquishes by blocking or yielding.
A thread using SCHED_FIFO must also have root authority to
use it. It is possible to create a thread with SCHED_FIFO that
has a high enough priority that it could monopolize the
processor.
SCHED_OTHER This is normal AIX scheduling and is the default, where priority
degrades with CPU usage.

The POSIX 1003.4a Draft 7 specification allows for alternative implementations of

threads. In particular, it allows for what is called an M:N implementation. While
this is not supported by AIX Version 4.1, it is discussed here for completeness.

In an M:N implementation, there can be user threads that are not permanently
attached to kernel threads, in addition to system scope threads as described
above. These threads are called process scope threads . This allows multiple
user threads to be scheduled and multiplexed onto a smaller number of kernel
threads. This is all done in user space, as part of the libpthreads function,
thereby reducing demand on system resources. This sort of implementation is
particularly advantageous for applications that have large numbers of threads,
most of which are waiting most of the time.

All process scope threads contend for resources within the process. They are
scheduled onto a smaller pool of system scope threads. The advantage of this is
when a process scope thread is running and it blocks, the system scope thread
suspends the user thread and starts running the next available process scope
thread. So the process scope threads are scheduled onto the system scope
threads and the kernel threads associated with the system scope threads are
scheduled onto the processors.

Chapter 13. Threads 227

Figure 19. Thread Architecture M:N

You can select the type of scheduling for process scope threads. You can have
normal round robin, FIFO, or “other.” The “other” scheduling mechanism is a
priority-based scheduling scheme similar to what the system scheduler provides.
“Other” is the default.

The scheduling of process scope threads is handled by the threads library,

libpthreads, via a new signal, SIGVIRT. The time slice can be varied between 0.1
- 1 second.

Process scope threads can have large time slices or no time slices at all (FIFO).
Because they contend with other process scope threads in the process for
access to the process′s system scope threads and the real processors, they
should not be used when real-time scheduling is needed.

In the M:N model, there can be system scope threads and single-threaded
processes in addition to process scope threads. Also, there can be both system
and process scope threads within a process. An application would use system

228 All About AIX Version 4.1

 scope threads if it needed real time scheduling onto the processor, and process
scope threads for those tasks which did not. This gives the programmer the
flexibility to easily balance and control resources.

13.6 Programming with Threads

13.6.1 Basic Facilities

AIX Version 4.1 provides a POSIX 1003.4a Draft 7 implementation of libpthreads.
This specification defines the user-level programming API for application
developers. The API provides facilities for threads creation and management,
threads communication and synchronization, and error handling. See 13.6.6,
“Libpthread API Detailed Design (LLD)” on page 234 for libpthread API details.

13.6.2 Process Control

There are two reasons why UNIX applications use fork():
1. One is to create a new thread of control within the same program. This use
can be replaced by pthread_create(), which creates a new thread in a
multi-threaded process. (Note that there is no requirement to change
applications to use threads rather than multiple processes; however, it may
be more efficient to do so.)
2. The other reason is to create a new process running a different program; the
call to fork() is then soon followed by a call to exec().

In a multi-threaded application, the semantics of fork() could be either to copy all

of the threads into the new process or to copy only the thread that calls fork().
The POSIX 1003.4a Draft 7 specification, written as it was by committee, keeps
both alternatives, making the first one optional.

13.6.2.1 Fork
In AIX Version 4.1, the child process is created with a single thread (the calling
thread). This new process contains a replica of the calling thread and its entire
address space at the time of the fork(). This means that the address space
could contain mutexes held by threads that do not exist in the child process.
Likewise, the data protected by these locks might not be in a consistent state. If
the child process attempts to acquire one of these mutexes, it could hang; if it
attempts to use the data protected by such a mutex, it could malfunction.
Therefore, any application using fork() in a multi-threaded application should
only execute safe operations between the call to fork() and exec(), to avoid
errors. (Safe operations are those that either do not take locks or are known to
be safe by the application.) Alternatively, fork handlers can be registered with
the pthread_atfork() routine in order to reset appropriate state.

Simultaneous fork() by different threads of the same process are serialized at

the kernel level.

Chapter 13. Threads 229

 13.6.2.2 Fork Handlers
The pthread_atfork() routine provides multi-threaded application programs with a
standard mechanism for protecting themselves from fork() calls in a library
routine or in the application itself.

The pthread_atfork() call registers three handlers to be called before and after
the call to the fork(). The three handlers are:
Prepare Called just before the fork() begins
Parent Called after the fork() is complete in the parent process
Child Called after the fork() is complete in the child process

The prepare fork handlers are called in last-in first-out (LIFO) order, whereas the
parent and child fork handlers are called in first-in first-out (FIFO) order. This
allows programs to preserve any desired locking order. The expected usage is
that the prepare handler acquires all mutex locks, and the other two handlers
release them.

pthread_atfork() handlers are implemented by having a new fork() routine that

replaces the libc fork() routine. This routine calls three new generic routines:
pthread_atfork_prepare(), pthread_atfork_parent(), and pthread_atfork_child().
These routines are defined in the libpthreads. They in turn call all the registered
pthread_atfork() handlers.

The POSIX 1003.4a Draft 7 specification defines a new function, forkall(). This
function solves the problem of inconsistent data between the child and the
parent by requiring that the child contain replicas of all threads in the parent.
This routine, defined under the _POSIX_THREAD_FORKALL option, is not
implemented in AIX Version 4.1. Also, this function, by solving one problem
associated with fork, introduces another one, which is how to deal with threads
suspended in system calls or about to execute system calls that should not be
executed in the new process.

13.6.3 Signals
According to the POSIX 1003.1 standard, the sigaction() function is used to
establish actions to be taken upon receipt of a signal. For each signal, it can be
called to specify one of three types of actions:
SIG_DFL Allow the signal-specific default action to happen.
SIG_IGN Ignore the signal.
A pointer to a function Call the function when the signal is delivered to catch
the signal.

The standard further specifies the default action for signals, and whether or not
they can be caught, blocked or ignored. This behavior can be quite complex,
due to use of the signal mechanism for a variety of different purposes.

The POSIX 1003.4a Draft 7 specification extends this behavior for threads with
the following points:
1. A signal is delivered exactly once (that is, one time to one thread)
2. The actions specified by sigaction() apply to the entire process (that is, to all
threads in the process)

230 All About AIX Version 4.1

 3. A thread can specify a private list of signals that are blocked from delivery to
that thread
In the case where there is only one thread in a process, the behavior given in
the POSIX 1003.4a Draft 7 specification is exactly the same as that required by
POSIX 1003.1.

13.6.3.1 Signal Delivery

Signals are considered to be either synchronous or asynchronous, depending on
whether they were caused by something that happened within the process.
Synchronous signals attributable to a particular thread are delivered to the
thread that caused the signal to be generated. An example of such a
synchronous signal is SIGFPE, the one sent when a program divides by zero.
The thread that caused the exception receives the signal. Some other
synchronous signals are SIGABRT, SIGILL, SIGPIPE and SIGSEGV.

Asynchronous signals, such as those generated by the kill() system call or by

terminal activity, are directed to the process and delivered to exactly one thread
in the process. The system chooses a thread from the following list:
1. A thread that has called sigwait() to wait for that signal
2. Any thread that has not blocked delivery of the signal
However, if all the threads in the process have blocked delivery of that signal
and are not waiting for it, the signal remains pending for the process until either:
• Some thread unblocks delivery of the signal, or
• Some thread calls sigwait() for the signal, or
• The action associated with the signal is changed to “ignore”

If the action associated with a signal is “terminate,” “stop,” or “continue,” the

entire process − all of its threads − is terminated, stopped, or continued.

All the rules in POSIX 1003.1 about which signals cannot be caught, blocked, or
ignored remain the same in a threaded environment.

13.6.3.2 Signal Management

Signal management in libpthreads is based on the signal management functions
provided by the AIX Version 4.1 kernel. Additionally, SIGVIRT and SIGALRM1
are used internally by libpthreads, and a multi-threaded application bound with
libpthreads should not specify a handler for these signals.

Signal Actions: The process can specify an action (accept the system default,
ignore the signal, or run a signal handler) associated with each signal. This
action is the same for all threads in the process. SIGSTOP and SIGKILL cannot
be caught or ignored.

Blocked Signals: Each thread has a signal mask that defines the set of signals
currently blocked from delivery to it. (Note that the POSIX 1003.1 standard
specifies that SIGKILL and SIGSTOP cannot be blocked, and that SIGCONT
continues a thread that is stopped, even if it has blocked SIGCONT.) The
sigaction(), sigsuspend(), and sigthreadmask() system calls control the
manipulation of the signal mask.

The kernel maintains a signal mask per kernel thread. Therefore, when the
calling thread is global, as in AIX Version 4.1 (which implements the 1:1 model),

Chapter 13. Threads 231

 the sigthreadmask() function can just call sigprocmask(). In the case of an M:N
implementation, the library would have to maintain a thread signal mask
invisible to the kernel, and set the signal mask of the kernel threads in the
process to match the signal mask of their corresponding user threads.

When a new thread is created via pthread_create(), it initially has no pending

signals. Its signal blocking mask is inherited from the creating thread.

A signal is automatically masked while being handled by a signal handler

defined via sigaction().

Pending Signals: The sigpending() function returns the union of the set of
signals pending for the thread or the process.

Send a Signal

Send a Signal to a Process

A process can send a signal to itself or another process with the kill() system
call. External events, such as terminal activity, can also send signals to a
process.

Send a Signal to a Thread

A thread can send a signal to a particular thread in the sending thread′s process
via pthread_kill(). (pthread_kill() cannot be used to send a signal from a thread
in one process to a thread in another process.)

The signal is delivered to the target thread if it does not block delivery of that
signal and the action associated with the signal is not “ignore.” If the signal
cannot be delivered, it remains pending until it is unblocked, it is selected by a
call to sigwait(), or the action associated with it is set to “ignore.”

Since AIX Version 4.1 implements a 1:1 model, libpthreads implements

pthread_kill by using the thread_kill() system call to send a signal to the
underlying kernel thread. In an M:N model, if the thread is active, the
libpthreads implementation would send a signal to the corresponding global
thread. If the thread is not running or waiting to be scheduled, delivery of the
signal would be postponed, and the signal marked pending. When the target
thread is run, the signal is sent to its global thread.

Wait for a Signal

Sigsuspend

The sigsuspend() function suspends the calling thread until any caught signal
arrives. It is similar to pause().

Sigwait

The POSIX 1003.4a Draft 7 specification defines a new interface, sigwait(), to wait
synchronously for a set of asynchronous signals. It returns the number of the
signal that ended the wait.

232 All About AIX Version 4.1

 Only asynchronous signals may be awaited by sigwait(). Synchronous
terminating signals such as SIGILL and SIGFPE cannot be awaited. SIGKILL and
SIGSTOP cannot be caught or blocked, and therefore cannot be awaited.

Furthermore, the signals defined by set must be blocked at the time of the call to
sigwait(). This means that, for a particular signal, a program cannot both specify
a signal handler with sigaction() and wait for it with sigwait().

When a thread does a sigwait(), if a signal is pending, the sigwait() returns at

once. If more than one thread is using sigwait() to wait for the same signal,
when that signal arrives, only one of these threads will return from the sigwait().

The sigwait() routine is fully implemented inside the libpthreads library. A global
handler is installed for all the signals waited for by sigwait(). A shadow thread is
then created for the entire process. When a sigwaited signal arrives, the signal
handler wakes up the shadow thread, which wakes up the thread waiting for it.
If a signal arrives and there is no thread waiting for it, the signal is re-raised.

13.6.4 Libraries
If you want to be able to write multi-threaded applications, then you will have to
link your programs with the libpthread library.

Two libraries are thread safe in AIX Version 4.1. There is a thread-safe libc
called libc_r. This is also needed by all multi-threaded applications. There is
also a thread-safe libbsd.

The libc_r, besides being thread safe, contains modifications to crt0() and fork()
to handle thread creation. A variety of other calls were changed internally to
handle threads cancellation conditions.

13.6.5 Scheduling

13.6.5.1 Existing Scheduling Interfaces

The AIX Version 3.2 interfaces for controlling process scheduling are:
nice( int Increment )
setpriority( int Which, int Who, int Priority )
getpriority( int Which, int Who )
setpri( pid_t ProcessID, int Priority )
getpri( pid_t ProcessID )
yield( void )

The interfaces nice() and setpriority()/getpriority() are maintained and continue to

be process based. That is, if a multi-threaded application calls one of these
interfaces which modifies the nice value for the process, this change will affect
all the threads in the process. getpriority() will return the nice value of the
process (which is the same for all threads in the process).

setpri()/getpri() are no longer interfaces defined by POSIX. In AIX Version 4.1,

setpri() fixes the priority of all the threads in the target process, and getpri()
returns the priority of the first thread in the process. (If a setpri() was done
previously for this process, then all the threads will have the same fixed priority
and the response from getpri() will be as expected.)

Chapter 13. Threads 233

 The system call yield() will place the caller on the end of the appropriate process
list. Since the schedulable entity for AIX Version 4.1 is the thread, this system
call will only cause the current thread to relinquish the CPU.

13.6.5.2 Threads Scheduling

When a thread is to be dispatched in an MP environment, a processor must be
chosen to run that thread. There are basically two choices:
1. The thread can run on the same processor all or most of the time. This is
called processor bondage .
This has some advantages, because the cache is likely to still contain both
data and instructions from the last execution of the thread. Moreover, the
system can avoid some overhead associated with moving the thread to
another processor. However, it has the disadvantage that it is possible for a
processor to become idle even where there is work to do because all
threads are bound to other processors.
2. The thread can run on any processor available. This is called opportunistic
affinity .
This has some advantages, in that the load on the system tends to be
balanced across all the available processors; and jobs, on the average, are
processed by the system as quickly as possible. However, it has the
disadvantage that the system must incur more overhead as it moves
processes from one processor to another.

AIX Version 4.1 implements an opportunistic strategy, but provides interfaces

that allow a thread to bind itself to a processor.

13.6.6 Libpthread API Detailed Design (LLD)

For details on threads programming, see the following articles in the ″Parallel
Programming Overview″ section of InfoExplorer:
• Understanding Threads
• Thread Programming Concepts
• Writing Re-entrant and Thread-Safe Code
• Developing Multi-Threaded Programs
• Threads Programming

13.6.6.1 New Threads Subroutines

The following new subroutines are added for threads support. See InfoExplorer
for details.
• pthread_atfork
• pthread_attr_destroy
• pthread_attr_getdetachstate
• pthread_attr_getinheritsched
• pthread_attr_getschedparam
• pthread_attr_getschedpolicy
• pthread_attr_getscope
• pthread_attr_getstackaddr
• pthread_attr_getstacksize
• pthread_attr_init
• pthread_attr_setdetachstate
• pthread_attr_setinheritsched
• pthread_attr_setschedparam

234 All About AIX Version 4.1

 • pthread_attr_setschedpolicy
• pthread_attr_setscope
• pthread_attr_setstackaddr
• pthread_attr_setstacksize
• pthread_cancel
• pthread_cleanup_pop
• pthread_cleanup_push
• pthread_condattr_destroy
• pthread_condattr_getpshared
• pthread_condattr_init
• pthread_condattr_setpshared
• pthread_cond_broadcast
• pthread_cond_destroy
• pthread_cond_init
• pthread_cond_signal
• pthread_cond_timedwait
• pthread_cond_wait
• pthread_create
• pthread_equal
• pthread_exit
• pthread_getschedparam
• pthread_getspecific
• pthread_join
• pthread_key_create
• pthread_key_delete
• pthread_kill
• pthread_mutexattr_destroy
• pthread_mutexattr_getprioceiling
• pthread_mutexattr_getprotocol
• pthread_mutexattr_getpshared
• pthread_mutexattr_init
• pthread_mutexattr_setprioceiling
• pthread_mutexattr_setprotocol
• pthread_mutexattr_setpshared
• pthread_mutex_destroy
• pthread_mutex_getprioceiling
• pthread_mutex_init
• pthread_mutex_lock
• pthread_mutex_setprioceiling
• pthread_mutex_trylock
• pthread_mutex_unlock
• pthread_once
• pthread_self
• pthread_setcancelstate
• pthread_setcanceltype
• pthread_setschedparam
• pthread_setspecific
• pthread_testcancel
• pthread_yield
• sigthreadmask

The following existing subroutines are changed for threads support:

• raise
• sigaction, sigvec, signal

Chapter 13. Threads 235

 • sigpending
• sigsuspend, sigpause, pause
• sigwait
• sleep, usleep, nsleep

13.6.6.2 New Kernel Services and System Calls

See 10.1.3, “AIX Version 3 Kernel Exports That Are Not Exported in AIX Version
4.1” on page 150 for additional information.

Processor-Dependent Synchronization Instructions

Import and export fences are special processor dependent synchronization

instructions. They temporarily block other reads and writes to these locations.
They protect against concurrent access by several processors, and against the
read and write reordering performed by modern processors. The following
synchronization subroutines are provided:
• _check_lock
• _clear_lock
• _safe_fetch

236 All About AIX Version 4.1