Pthread glossary
A
- attribute object
- Any of the Pthreads data structures that are used to specify the initial states when creating certain resources (threads, mutexes, and condition variables). A thread attribute object can be used to create a thread. A mutex attributes object can be used to create a mutex. A condition attributes object can be used to create a condition. Functions that create attribute objects are pthread_attr_init(), pthread_mutexattr_init(), and pthread_condattr_init().
C
- cancel
- A cancel is delivered to a thread when pthread_cancel() is issued and stops
a thread. A cancel can be held pending if the target thread has cancellation
DISABLED or DEFERRED. The cancel may be acted upon when cancellation is set to
ENABLED or ASYNCHRONOUS.
- cancellation cleanup handler
- A function registered to perform some cleanup action. Cancellation cleanup
handlers are called if a thread calls pthread_exit() or is the target of a
pthread_cancel(). Cancellation cleanup handlers are stacked onto a cancellation
cleanup stack and can be pushed and popped using the pthread_cleanup_push() and
pthread_cleanup_pop() functions.
- cancellation point
- A function that causes a pending cancel to be delivered if the cancellation
state is ENABLED, and the cancellation type is DEFERRED. pthread_testcancel()
can be used to create a cancellation point. For a list of other functions that
are cancellation points, see pthread_cancel().
- cancellation state
- Either of two values (ENABLED or DISABLED) that describe whether cancels in
the current thread are acted upon or held pending, If ENABLED, the cancellation
is acted upon immediately based on the current cancellation type. If DISABLED,
the cancel is held pending until it is ENABLED. You can modify the cancellation
state using the pthread_setcancelstate() function.
- cancellation type
- Either of two values (DEFERRED or ASYNCHRONOUS) that describe how cancels
are acted upon in the current thread when the cancellation state is ENABLED. If
DEFERRED, the cancel is held pending, if ASYNCHRONOUS, the cancel is acted upon
immediately, thus ending the thread with a status of PTHREAD_CANCELED. You can
modify the cancellation type using the pthread_setcanceltype() function.
- condition variable
- An object that allows a thread to suspend execution when it finds an untrue condition, and to resume execution when another thread makes the condition true.
D
- detach a thread
- To mark a thread so that the system reclaims the thread resources when the thread ends. If the thread has already ended, the resources are freed immediately. After a thread's resources are freed, the exit status is no longer available, and the thread cannot be detached or joined to. Use the pthread_attr_setdetachstate(), or pthread_detach() functions to detach a thread, or the pthread_join() function to wait for and then detach a thread.
E
- exit status
- The return value from a thread. A variable of type void *, which typically contains some pointer to a control block pointer or return value, that shows under what conditions the thread ended. The thread can be ended and the exit status can be set by returning from the thread start routine, by calling pthread_exit(), or by canceling a thread using pthread_cancel().
G
- global mutex
- A single mutex that is stored globally to the process that is provided by the pthreads library to allow easy serialization (a mechanism that allows only one thread to act at one time) to application resources. See the functions pthread_lock_global_np() or pthread_unlock_global_np().
I
- initial thread
- The thread that is started automatically by the system when a job or process is started. Every job has at least one thread. That thread is often referred to as the initial thread or the primary thread. Threads other than the initial thread are referred to as secondary threads. If the initial thread ends, it causes all secondary threads and the job to end. See also `Secondary thread'.
J
- join to a thread
- To wait for a thread to complete, detach the thread, and optionally return its exit status. Use pthread_join() to wait for a thread to complete.
M
- main thread
- See initial thread.
- multithread capable
- This term is specific to the IBM® i operating system. See thread capable.
- multithreaded
- A process that has multiple active threads. In the IBM i documentation,
the term multithreaded is sometimes used as a synomym for multithread capable.
- mutex
- An abstraction that allows two or more threads to cooperate in a MUTual EXclusion protocol that allows safe access to shared resources. See pthread_mutex_init() or other functions whose names begin with pthread_mutex_. Also see recursive mutex, named mutex, global mutex.
N
- named mutex
- A mutex with an associated text name used for identification and debugging. The name is used in some system dumps and debug or thread-management user interfaces. The name does not affect the behavior of the mutex, only the ability to debug the use of that mutex. The Pthread run-time names all mutexes by default. See the functions pthread_mutexattr_setname_np() or pthread_mutexattr_getname_np().
O
- orphaned mutex
- A mutex that was held by a thread when that thread ended. Any application data or resources associated with the mutex are most likely in an inconsistent state if a mutex is orphaned. An orphaned mutex is not available to be locked by another thread and causes a locking thread to block indefinitely or to get the EBUSY error when attempting to trylock the mutex.
P
- POSIX thread handle
- The pthread_t data type that is returned to a creator of a POSIX thread.
The pthread_t represents an opaque handle to the POSIX thread. It should not be
modified except through the use of the pthread functions. The pthread_create()
or pthread_self() function returns the POSIX thread handle. The pthread_equal()
function can be used to confirm whether two handles refer to the same thread.
The POSIX thread handle is sometimes referred to as the thread ID.
- primary thread
- See initial thread.
- Pthread
- Shorthand for POSIX or Single UNIX Specification Thread, as in the interfaces described in this document are based on the POSIX standard (ANSI/IEEE Standard 1003.1, 1996 Edition OR ISO/IEC 9945-1: 1996) and the Single UNIX Specification, Version 2, 1997'.
R
- recursive mutex
- A mutex that can be acquired again by the owning thread. A recursive mutex does not become unlocked until the number of unlock requests equals the number of successful lock requests. A non-recursive (normal) mutex causes an EDEADLK error if an attempt is made by the owning thread to lock it a second time. See the functions pthread_mutexattr_setkind_np() or pthread_mutexattr_getkind_np().
S
- scheduling parameters
- Information describing the scheduling characteristics of a thread. The
sched_param structure contains scheduling parameters. On the IBM i operating system, the
scheduling parameters allow you to only specify the priority of the thread.
Scheduling Policy is restricted to the proprietary IBM i scheduling policy. Use the pthread_attr_setschedparam(), pthread_attr_getschedparam(), pthread_setschedparam(),
or pthread_getschedparam() functions to manipulate scheduling parameters.
- scheduling policy
- Information describing which algorithm is used to schedule threads within
the process or system. Some scheduling policies are Round Robin or FIFO. The
IBM i operating system uses the SCHED_OTHER constant to indicate the delay cost scheduling. The scheduling parameter functions support only the
SCHED_OTHER policy, and the pthread_attr_getschedpolicy() and
pthread_attr_setschedpolicy() functions are not supported.
- scope
- Information describing whether the scheduling policy indicates that threads
compete directly with other threads within the process or the system. The IBM i operating system schedules threads within the system, and the pthread_attr_setscope() and
pthread_attr_getscope() functions are not supported.
- secondary thread
- Any thread started by or on behalf of the application that is not the
initial thread. Secondary threads are started by calling pthread_create() or
another library service that creates threads. Secondary threads have no
parent/child relationship.
- signal
- An asynchronous mechanism for interrupting the processing of a thread. The
system delivers a signal to a thread when the application programmer takes
explicit or implicit action to cause the signal to be delivered. The signal can
be sent to a thread or process, but is always delivered to a specific
thread.
- signal handler
- A function registered by the application programmer that the system
executes when a signal is delivered to a thread. The function runs immediately
in the thread, interrupting any application processing that is in progress.
- signal safe
- A function, macro or operating system service that can be called safely
from a signal handler. The function always acts in a well-defined manner. It
does not rely on any external state or locks that might be in an inconsistent
state at the time the signal handler function is called by the system.
- signal unsafe
- A function, macro or operating system service that cannot be called safely from within a signal handler. A signal unsafe function may acquire locks or otherwise change the state of a resource. When the signal is delivered to the thread, the signal handler runs. The state of the resource or the lock managed by the signal unsafe function is unknown because it was interrupted by the signal before it completed. If the signal unsafe function is called again, the results are non-deterministic.
T
- thread
- An independent sequence of execution of program code and processing context
inside a process. A unique unit of work or flow of control within a process. A
thread runs a procedure asynchronously with other threads running the same or
different procedures within the process. All threads within a process equally
share activation group and process resources (heap storage, static storage,
open files, socket descriptors, other communications ports, environment
variables, and so on). A thread has few resources (mutexes, locks, automatic
storage, thread specific storage) that are not shared. On a multiprocessor
system, multiple threads in a process can run concurrently.
- thread-capable job
- The only job that can create threads. Certain system behavior and the
architecture of the process changes slightly to support IBM i threads. If a
job is not thread capable, attempts to create a thread result in the EBUSY
error. You can create a thread-capable process by using the spawn() interface
or by using other IBM i job-creation commands that allow you to specify
that the new job should be thread capable.
- thread ID
- The unique integral number can be used to identify the thread. This
integral number is available for retrieval using the pthread_getunique_np()
interface. Although no Pthread interfaces use the integral thread ID to
identify a thread for manipulation, thread ID is sometimes used to describe the
pthread_t data type that represents the abstraction to a thread. See POSIX
thread handle.
- thread local storage (TLS)
- See thread specific storage.
- threadsafe
- A function, macro or operating system service that can be called from
multiple threads in a process at the same time. The function always acts in a
well-defined manner. The end results are as if the function was called by each
thread in turn, even though all of the threads were running the function at the
same time. Some APIs have restrictions about how they can be called in order
for them to be thread safe. See the API documentation for all APIs or system
services that you use in a multithreaded job.
- thread specific storage
- Storage that is not shared between threads, but that can be accessed by all
functions within that thread. Usually, thread specific storage is indexed by a
key. The key is a global value visible to all threads, and it is used to
retrieve the thread-specific value of the storage associated with that key.
Also called thread private storage, thread local storage or TLS. See the
pthread_getspecific(), pthread_setspecific(), pthread_key_create(), and
pthread_key_delete() functions.
- thread unsafe
- A function, macro, or operating system service that cannot be called from multiple threads is called thread unsafe. If this function is used in multiple threads or in a process that has multiple threads active, the results are undefined. A thread unsafe function can corrupt or negatively interact with data in another function (thread safe or otherwise) that appears to be unrelated to the first function. Do NOT use thread unsafe functions in your multithreaded application. Do NOT call programs or service programs that use thread-unsafe functions. See the API documentation for all APIs or system services that you use in a multithreaded job.
[ Back to top | Pthread APIs | APIs by category ]