2
0
mirror of https://github.com/boostorg/thread.git synced 2026-01-22 17:52:18 +00:00
Files
thread/doc/definitions.html
2002-04-26 20:41:25 +00:00

264 lines
12 KiB
HTML

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link rel="stylesheet" type="text/css" href="../../../boost.css">
<title>Boost.Threads - Definitions</title>
</head>
<body link="#0000ff" vlink="#800080">
<table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
"header">
<tr>
<td valign="top" width="300">
<h3><a href="../../../index.htm"><img height="86" width="277" alt="C++ Boost" src="../../../c++boost.gif" border="0"></a></h3>
</td>
<td valign="top">
<h1 align="center">Boost.Threads</h1>
<h2 align="center">Definitions</h2>
</td>
</tr>
</table>
<hr>
<h2>Contents</h2>
<dl class="page-index">
<dt><a href="#introduction">Introduction</a></dt>
<dt><a href="#definitions">Definitions</a></dt>
<dl class="page-index">
<dt><a href="#definition-thread">Thread</a></dt>
<dt><a href="#definition-thread-safe">Thread-safe</a></dt>
<dt><a href="#definition-thread-state">Thread State</a></dt>
<dt><a href="#definition-race-condition">Race Condition</a></dt>
<dt><a href="#definition-deadlock">Deadlock</a></dt>
<dt><a href="#definition-starvation">Starvation</a></dt>
<dt><a href="#definition-priority-failure">Priority Failure</a></dt>
<dt><a href="#definition-visibility">Memory Visibility</a></dt>
</dl>
<dt><a href="#acknowledgements">Acknowledgments</a></dt>
</dl>
<hr>
<h2><a name="introduction"></a>Introduction</h2>
<p>The definitions are given in terms of the <a href=
"bibliography.html#ISO-98">C++ Standard</a>. References to the standard
are in the form [1.2.3/4], which represents the section number, with the paragraph
number following the &quot;/&quot;.</p>
<p>Because the definitions are written in something akin to &quot;standardese&quot;,
they can be difficult to understand. The intent isn&#39;t to confuse, but rather
to clarify the additional requirements Boost.Threads places on a C++ implementation
as defined by the C++ Standard.</p>
<h2><a name="definitions"></a>Definitions</h2>
<h3><a name="definition-thread"></a>Thread</h3>
<p>Thread is short for &quot;thread of execution&quot;. A thread of execution
is an execution environment [1.9/7] within the execution environment of a C++
program [1.9]. The main() function [3.6.1] of the program is the initial function
of the initial thread. A program in a multithreading environment always has
an initial thread even if the program explicitly creates no additional threads.</p>
<p>Unless otherwise specified, each thread shares all aspects of its execution
environment with other threads in the program. Shared aspects of the execution
environment include, but are not limited to, the following:</p>
<ul>
<li>Static storage duration (static, extern) objects [3.7.1].</li>
</ul>
<ul>
<li>Dynamic storage duration (heap) objects [3.7.3]. Thus each memory allocation
will return a unique addresses, regardless of the thread making the allocation
request.</li>
</ul>
<ul>
<li>Automatic storage duration (stack) objects [3.7.2] accessed via pointer
or reference from another thread.</li>
</ul>
<ul>
<li>Resources provided by the operating system. For example, files.</li>
</ul>
<ul>
<li>The program itself. In other words, each thread is executing some function
of the same program, not a totally different program.</li>
</ul>
<p>Each thread has its own:</p>
<ul>
<li>Registers and current execution sequence (program counter) [1.9/5].</li>
</ul>
<ul>
<li>Automatic storage duration (stack) objects [3.7.2].</li>
</ul>
<h3><a name="definition-thread-safe"></a>Thread-safe</h3>
<p>A program is thread-safe if it has no <a href="#Race condition">race conditions</a>,
does not <a href="#Deadlock">deadlock</a>, and has no <a href="#Priority failure">priority
failures</a>.</p>
<p>Note that thread-safety does not necessarily imply efficiency, and than while
some thread-safety violations can be determined statically at compile time,
many thread-safety errors can only only be detected at runtime.</p>
<h3><a name="definition-thread-state"></a>Thread State</h3>
<p>During the lifetime of a thread, it shall be in one of the following states:</p>
<table summary="thread states" border="1" cellpadding="5">
<tr>
<td><b>State</b></td>
<td><b>Description</b></td>
</tr>
<tr>
<td>Ready</td>
<td>Ready to run, but waiting for a processor.</td>
</tr>
<tr>
<td>Running</td>
<td>Currently executing on a processor. Zero or more threads may be running
at any time, with a maximum equal to the number of processors.</td>
</tr>
<tr>
<td>Blocked</td>
<td>Waiting for some resource other than a processor which is not currently
available, or for the completion of calls to library functions [1.9/6].
The term &quot;waiting&quot; is synonymous for &quot;blocked&quot;</td>
</tr>
<tr>
<td>Terminated</td>
<td>Finished execution but not yet detached or joined.</td>
</tr>
</table>
<p>Thread state transitions shall occur only as specified:</p>
<table summary="state transitions" border="1" cellpadding="5">
<tr>
<td><b>From</b></td>
<td><b>To</b></td>
<td><b>Cause</b></td>
</tr>
<tr>
<td>
<p align="left">[none]</p>
</td>
<td>Ready</td>
<td>Thread is created by a call to a library function. In the case of the
initial thread, creation is implicit and occurs during the startup of the
main() function [3.6.1].</td>
</tr>
<tr>
<td>Ready</td>
<td>Running</td>
<td>Processor becomes available.</td>
</tr>
<tr>
<td>Running</td>
<td>Ready</td>
<td>Thread preempted.</td>
</tr>
<tr>
<td>Running</td>
<td>Blocked</td>
<td>Thread calls a library function which waits for a resource or for the
completion of I/O.</td>
</tr>
<tr>
<td>Running</td>
<td>Terminated</td>
<td>Thread returns from its initial function, calls a thread termination library
function, or is canceled by some other thread calling a thread termination
library function.</td>
</tr>
<tr>
<td>Blocked</td>
<td>Ready</td>
<td>The resource being waited for becomes available, or the blocking library
function completes.</td>
</tr>
<tr>
<td>Terminated</td>
<td>[none]</td>
<td>Thread is detached or joined by some other thread calling the appropriate
library function, or by program termination [3.6.3].</td>
</tr>
</table>
<p>[Note: if a suspend() function is added to the threading library, additional
transitions to the blocked state will have to be added to the above table.]</p>
<h3><a name="definition-race-condition"></a>Race Condition</h3>
<p>A race condition is what occurs when multiple threads read and write to the
same memory without proper synchronization, resulting in an incorrect value
being read or written. The result of a race condition may be a bit pattern which
isn&#39;t even a valid value for the data type. A race condition results in
undefined behavior [1.3.12].</p>
<p>Race conditions can be prevented by serializing memory access using the tools
provided by Boost.Threads.</p>
<h3><a name="definition-deadlock"></a>Deadlock</h3>
<p>Deadlock is an execution state where for some set of threads, each thread in
the set is blocked waiting for some action by one of the other threads in the
set. Since each is waiting on the others, none will ever become ready again.</p>
<h3><a name="definition-starvation"></a>Starvation</h3>
<p>The condition in which a thread is not making sufficient progress in its work
during a given time interval.</p>
<h3><a name="definition-priority-failure"></a>Priority Failure</h3>
<p>A priority failure (such as priority inversion or infinite overtaking) occurs
when threads executed in such a sequence that required work is not performed
in time to be useful.</p>
<h3><a name="definition-visibility"></a>Memory Visibility</h3>
<p>An address [1.7] shall always point to the same memory byte, regardless of
the thread or processor dereferencing the address.</p>
<p>An object [1.8, 1.9] is accessible from multiple threads if it is of static
storage duration (static, extern) [3.7.1], or if a pointer or reference to it
is explicitly or implicitly dereferenced in multiple threads.</p>
<p>For an object accessible from multiple threads, the value of the object accessed
from one thread may be indeterminate or different than the value accessed from
another thread, except under the conditions specified in the following table.
For the same row of the table, the value of an object accessible at the indicated
sequence point in thread A will be determinate and the same if accessed at or
after the indicated sequence point in thread B, provided the object is not otherwise
modified. In the table, the &quot;sequence point at a call&quot; is the sequence
point after the evaluation of all function arguments [1.9/17], while the &quot;sequence
point after a call&quot; is the sequence point after the copying of the returned
value...&quot; [1.9/17].</p>
<table summary="memory visibility" border="1" cellpadding="5">
<tr>
<td align="center"><b>Thread A</b></td>
<td align="center"><b>Thread B</b></td>
</tr>
<tr>
<td>The sequence point at a call to a library thread-creation function.</td>
<td>The first sequence point of the initial function in the new thread created
by the Thread A call.</td>
</tr>
<tr>
<td>The sequence point at a call to a library function which locks a mutex,
directly or by waiting for a condition variable.</td>
<td>The sequence point after a call to a library function which unlocks the
same mutex.</td>
</tr>
<tr>
<td>The last sequence point before thread termination.</td>
<td>The sequence point after a call to a library function which joins the
terminated thread.</td>
</tr>
<tr>
<td>The sequence point at a call to a library function which signals or broadcasts
a condition variable.</td>
<td>The sequence point after the call to the library function which was waiting
on that same condition variable or signal.</td>
</tr>
</table>
<p>The architecture of the execution environment and the observable behavior of
the abstract machine [1.9] shall be the same on all processors.</p>
<p>The latitude granted by the C++ standard for an implementation to alter the
definition of observable behavior of the abstract machine to include additional
library I/O functions [1.9/6] is extended to include threading library functions.</p>
<p>When an exception is thrown and there is no matching exception handler in the
same thread, behavior is undefined. The preferred behavior is the same as when
there is no matching exception handler in a program [15.3/9]. That is, terminate()
is called, and it is implementation defined whether or not the stack is unwound.</p>
<h2><a name="acknowledgements"></a>Acknowledgments</h2>
<p>This document has been much improved by the incorporation of comments from
William Kempf.</p>
<p>The visibility rules are based on <a href=
"bibliography.html#Butenhof-97">[Butenhof 97]</a>.</p>
<hr>
<p>Revised
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
05 November, 2001
<!--webbot bot="Timestamp" endspan i-checksum="39359" -->
</p>
<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
All Rights Reserved.</i></p>
<p>Permission to use, copy, modify, distribute and sell this software and its
documentation for any purpose is hereby granted without fee, provided that the
above copyright notice appear in all copies and that both that copyright notice
and this permission notice appear in supporting documentation. William E. Kempf
makes no representations about the suitability of this software for any purpose.
It is provided &quot;as is&quot; without express or implied warranty.</p>
</body>
</html>