Planet
navi homePPSaboutscreenshotsdownloaddevelopmentforum

source: downloads/boost_1_33_1/libs/thread/doc/design.xml @ 12

Last change on this file since 12 was 12, checked in by landauf, 17 years ago

added boost

File size: 7.8 KB
Line 
1<?xml version="1.0" encoding="utf-8"?>
2<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
3  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
4  <!ENTITY % threads.entities SYSTEM "entities.xml">
5  %threads.entities;
6]>
7<section id="threads.design" last-revision="$Date: 2004/07/17 04:33:59 $">
8  <title>Design</title>
9  <para>With client/server and three-tier architectures becoming common place
10  in today's world, it's becoming increasingly important for programs to be
11  able to handle parallel processing. Modern day operating systems usually
12  provide some support for this through native thread APIs. Unfortunately,
13  writing portable code that makes use of parallel processing in C++ is made
14  very difficult by a lack of a standard interface for these native APIs.
15  Further, these APIs are almost universally C APIs and fail to take
16  advantage of C++'s strengths, or to address concepts unique to C++, such as
17  exceptions.</para>
18  <para>The &Boost.Threads; library is an attempt to define a portable interface
19  for writing parallel processes in C++.</para>
20  <section id="threads.design.goals">
21    <title>Goals</title>
22    <para>The &Boost.Threads; library has several goals that should help to set
23        it apart from other solutions. These goals are listed in order of precedence
24        with full descriptions below.
25    <variablelist>
26          <varlistentry>
27            <term>Portability</term>
28                <listitem>
29          <para>&Boost.Threads; was designed to be highly portable. The goal is
30                  for the interface to be easily implemented on any platform that
31                  supports threads, and possibly even on platforms without native thread
32                  support.</para>
33                </listitem>
34          </varlistentry>
35          <varlistentry>
36        <term>Safety</term>
37        <listitem>
38          <para>&Boost.Threads; was designed to be as safe as possible. Writing
39                  <link linkend="threads.glossary.thread-safe">thread-safe</link>
40                  code is very difficult and successful libraries must strive to
41                  insulate the programmer from dangerous constructs as much as
42                  possible. This is accomplished in several ways:
43          <itemizedlist>
44            <listitem>
45              <para>C++ language features are used to make correct usage easy
46                          (if possible) and error-prone usage impossible or at least more
47                          difficult. For example, see the <link
48                          linkend="threads.concepts.Mutex">Mutex</link> and <link
49                          linkend="threads.concepts.Lock">Lock</link> designs, and note
50                          how they interact.</para>
51            </listitem>
52            <listitem>
53              <para>Certain traditional concurrent programming features are
54                          considered so error-prone that they are not provided at all. For
55                          example, see <xref linkend="threads.rationale.events" />.</para>
56            </listitem>
57            <listitem>
58              <para>Dangerous features, or features which may be misused, are
59              identified as such in the documentation to make users aware of
60              potential pitfalls.</para>
61            </listitem>
62          </itemizedlist></para>
63                </listitem>
64          </varlistentry>
65      <varlistentry>
66            <term>Flexibility</term>
67                <listitem>
68                  <para>&Boost.Threads; was designed to be flexible. This goal is often
69                  at odds with <emphasis>safety</emphasis>. When functionality might be
70                  compromised by the desire to keep the interface safe, &Boost.Threads;
71                  has been designed to provide the functionality, but to make it's use
72                  prohibitive for general use. In other words, the interfaces have been
73                  designed such that it's usually obvious when something is unsafe, and
74                  the documentation is written to explain why.</para>
75        </listitem>
76          </varlistentry>
77      <varlistentry>
78        <term>Efficiency</term>
79                <listitem>
80          <para>&Boost.Threads; was designed to be as efficient as
81                  possible. When building a library on top of another library there is
82                  always a danger that the result will be so much slower than the
83                  "native" API that programmers are inclined to ignore the higher level
84                  API. &Boost.Threads; was designed to minimize the chances of this
85                  occurring. The interfaces have been crafted to allow an implementation
86                  the greatest chance of being as efficient as possible. This goal is
87                  often at odds with the goal for <emphasis>safety</emphasis>. Every
88                  effort was made to ensure efficient implementations, but when in
89                  conflict <emphasis>safety</emphasis> has always taken
90                  precedence.</para>
91        </listitem>
92          </varlistentry>
93    </variablelist></para>
94  </section>
95  <section>
96    <title>Iterative Phases</title>
97    <para>Another goal of &Boost.Threads; was to take a dynamic, iterative
98        approach in its development. The computing industry is still exploring the
99        concepts of parallel programming. Most thread libraries supply only simple
100        primitive concepts for thread synchronization. These concepts are very
101        simple, but it is very difficult to use them safely or to provide formal
102        proofs for constructs built on top of them. There has been a lot of research
103        into other concepts, such as in "Communicating Sequential Processes."
104        &Boost.Threads; was designed in iterative steps, with each step providing
105        the building blocks necessary for the next step and giving the researcher
106        the tools necessary to explore new concepts in a portable manner.</para>
107    <para>Given the goal of following a dynamic, iterative approach
108        &Boost.Threads; shall go through several growth cycles. Each phase in its
109        development shall be roughly documented here.</para>
110  </section>
111  <section>
112    <title>Phase 1, Synchronization Primitives</title>
113    <para>Boost is all about providing high quality libraries with
114        implementations for many platforms. Unfortunately, there's a big problem
115        faced by developers wishing to supply such high quality libraries, namely
116        thread-safety. The C++ standard doesn't address threads at all, but real
117        world programs often make use of native threading support. A portable
118        library that doesn't address the issue of thread-safety is therefore not
119        much help to a programmer who wants to use the library in his multithreaded
120        application. So there's a very great need for portable primitives that will
121        allow the library developer to create <link
122        linkend="threads.glossary.thread-safe">thread-safe</link>
123        implementations. This need far out weighs the need for portable methods to
124        create and manage threads.</para>
125    <para>Because of this need, the first phase of &Boost.Threads; focuses
126        solely on providing portable primitive concepts for thread
127        synchronization. Types provided in this phase include the
128        <classname>boost::mutex</classname>,
129        <classname>boost::try_mutex</classname>,
130        <classname>boost::timed_mutex</classname>,
131        <classname>boost::recursive_mutex</classname>,
132        <classname>boost::recursive_try_mutex</classname>,
133        <classname>boost::recursive_timed_mutex</classname>, and
134        <classname>boost::lock_error</classname>. These are considered the "core"
135        synchronization primitives, though there are others that will be added in
136        later phases.</para>
137  </section>
138  <section id="threads.design.phase2">
139    <title>Phase 2, Thread Management and Thread Specific Storage</title>
140    <para>This phase addresses the creation and management of threads and
141    provides a mechanism for thread specific storage (data associated with a
142    thread instance). Thread management is a tricky issue in C++, so this
143    phase addresses only the basic needs of multithreaded program. Later
144    phases are likely to add additional functionality in this area. This
145    phase of &Boost.Threads; adds the <classname>boost::thread</classname> and
146        <classname>boost::thread_specific_ptr</classname> types. With these
147        additions the &Boost.Threads; library can be considered minimal but
148        complete.</para>
149  </section>
150  <section>
151    <title>The Next Phase</title>
152    <para>The next phase will address more advanced synchronization concepts,
153    such as read/write mutexes and barriers.</para>
154  </section>
155</section>
Note: See TracBrowser for help on using the repository browser.