ibm-information-center/dist/eclipse/plugins/i5OS.ic.apis_5.4.0.1/glossary.htm

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>