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> |
---|