452 lines
16 KiB
HTML
452 lines
16 KiB
HTML
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
|
|
<html>
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
||
|
|
<meta name="Copyright" content="Copyright (c) 2006 by IBM Corporation">
|
||
|
|
<title>Pthread glossary</title>
|
||
|
|
<!-- Begin Header Records ========================================== -->
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<!-- Change History: -->
|
||
|
|
<!-- NETMG2 SCRIPT A converted by B2H R4.1 (346) (CMS) by HOLTJM at -->
|
||
|
|
<!-- RCHVMW2 on 29 Jan 1999 at 10:01:37 -->
|
||
|
|
<!--File Edited November 2001 -->
|
||
|
|
<!--End Header Records -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="../rzahg/ic.css">
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
|
||
|
|
<!-- Java sync-link -->
|
||
|
|
<script language="Javascript" src="../rzahg/synch.js" type="text/javascript">
|
||
|
|
</script>
|
||
|
|
|
||
|
|
<a name="Top_Of_Page"></a>
|
||
|
|
|
||
|
|
<h2>Pthread glossary</h2>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
<h2>A</h2>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><strong>attribute object</strong></dt>
|
||
|
|
|
||
|
|
<dd>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().</dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
<h2>C</h2>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><strong>cancel</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>cancellation cleanup handler</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>cancellation point</strong></dt>
|
||
|
|
|
||
|
|
<dd>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().<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>cancellation state</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>cancellation type</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>condition variable</strong></dt>
|
||
|
|
|
||
|
|
<dd>An abstraction that allows a thread to wait for an event to occur. The
|
||
|
|
condition variable is used with a Boolean predicate that indicates the presence
|
||
|
|
or absence of the event and a mutex that protects both the predicate and the
|
||
|
|
resources associated with the event. The condition variable has no ownership
|
||
|
|
associated with it. See pthread_cond_init(), and other functions whose names
|
||
|
|
begin with pthread_cond_.</dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
<h2>D</h2>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><strong>detach a thread</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.</dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
<h2>E</h2>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><strong>exit status</strong></dt>
|
||
|
|
|
||
|
|
<dd>The return value from a thread. A variable of type <strong>void *</strong>,
|
||
|
|
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().</dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
<h2>G</h2>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><strong>global mutex</strong></dt>
|
||
|
|
|
||
|
|
<dd>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().</dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
<h2>I</h2>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><strong>initial thread</strong></dt>
|
||
|
|
|
||
|
|
<dd>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'.</dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
<h2>J</h2>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><strong>join to a thread</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.</dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
<h2>M</h2>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><strong>main thread</strong></dt>
|
||
|
|
|
||
|
|
<dd>See initial thread.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>multithread capable</strong></dt>
|
||
|
|
|
||
|
|
<dd>This term is specific to iSeries. See thread capable.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>multithreaded</strong></dt>
|
||
|
|
|
||
|
|
<dd>A process that has multiple active threads. In the iSeries documentation,
|
||
|
|
the term multithreaded is sometimes used as a synomym for multithread
|
||
|
|
capable.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>mutex</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.</dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
<h2>N</h2>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><strong>named mutex</strong></dt>
|
||
|
|
|
||
|
|
<dd>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().</dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
<h2>O</h2>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><strong>orphaned mutex</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.</dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
<h2>P</h2>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><strong>POSIX thread handle</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>primary thread</strong></dt>
|
||
|
|
|
||
|
|
<dd>See initial thread.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>Pthread</strong></dt>
|
||
|
|
|
||
|
|
<dd>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'.</dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
<h2>R</h2>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><strong>recursive mutex</strong></dt>
|
||
|
|
|
||
|
|
<dd>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().</dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
<h2>S</h2>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><strong>scheduling parameters</strong></dt>
|
||
|
|
|
||
|
|
<dd>Information describing the scheduling characteristics of a thread. The
|
||
|
|
sched_param structure contains scheduling parameters. On the iSeries, the
|
||
|
|
scheduling parameters allow you to only specify the priority of the thread.
|
||
|
|
Scheduling Policy is restricted to the proprietary iSeries scheduling policy.
|
||
|
|
Use the pthread_attr_setschedparam(), pthread_attr_getschedparam(),
|
||
|
|
pthread_setschedparam(), or pthread_getschedparam() functions to manipulate
|
||
|
|
scheduling parameters.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>scheduling policy</strong></dt>
|
||
|
|
|
||
|
|
<dd>Information describing which algorithm is used to schedule threads within
|
||
|
|
the process or system. Some scheduling policies are Round Robin or FIFO.
|
||
|
|
iSeries uses the SCHED_OTHER constant to indicate the delay cost scheduling
|
||
|
|
that the system uses. The scheduling parameter functions support only the
|
||
|
|
SCHED_OTHER policy, and the pthread_attr_getschedpolicy() and
|
||
|
|
pthread_attr_setschedpolicy() functions are not supported.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>scope</strong></dt>
|
||
|
|
|
||
|
|
<dd>Information describing whether the scheduling policy indicates that threads
|
||
|
|
compete directly with other threads within the process or the system. iSeries
|
||
|
|
schedules threads within the system, and the pthread_attr_setscope() and
|
||
|
|
pthread_attr_getscope() functions are not supported.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>secondary thread</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>signal</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>signal handler</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>signal safe</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>signal unsafe</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.</dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
<h2>T</h2>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><strong>thread</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>thread capable job</strong></dt>
|
||
|
|
|
||
|
|
<dd>The only job that can create threads. Certain system behavior and the
|
||
|
|
architecture of the process changes slightly to support i5/OS 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 iSeries job-creation commands that allow you to specify that
|
||
|
|
the new job should be thread capable.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>thread ID</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>thread local storage (TLS)</strong></dt>
|
||
|
|
|
||
|
|
<dd>See thread specific storage.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>threadsafe</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>thread specific storage</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.<br>
|
||
|
|
<br>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><strong>thread unsafe</strong></dt>
|
||
|
|
|
||
|
|
<dd>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.</dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<hr>
|
||
|
|
<center>
|
||
|
|
<table cellpadding="2" cellspacing="2">
|
||
|
|
<tr align="center">
|
||
|
|
<td valign="middle" align="center"><a href="#Top_Of_Page">Top</a> | <a href=
|
||
|
|
"rzah4mst.htm">Pthread APIs</a> | <a href="aplist.htm">APIs by
|
||
|
|
category</a></td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</center>
|
||
|
|
</body>
|
||
|
|
</html>
|
||
|
|
|