1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="AUTHOR" CONTENT="pme@sources.redhat.com (Phil Edwards)">
<META NAME="KEYWORDS" CONTENT="HOWTO, libstdc++, gcc, g++, libg++, STL">
<META NAME="DESCRIPTION" CONTENT="HOWTO for libstdc++ chapter 17.">
<META NAME="GENERATOR" CONTENT="vi and eight fingers">
<TITLE>libstdc++-v3 HOWTO: Chapter 17</TITLE>
<LINK REL=StyleSheet HREF="../lib3styles.css">
<!-- $Id: howto.html,v 1.1.4.3 2001/05/31 02:48:49 ljrittle Exp $ -->
</HEAD>
<BODY>
<H1 CLASS="centered"><A NAME="top">Chapter 17: Library Introduction</A></H1>
<P>Chapter 17 is actually a list of definitions and descriptions used
in the following chapters of the Standard when describing the actual
library. Here, we use "Introduction" as an introduction
to the <EM>GNU implementation of</EM> the ISO Standard C++ Library.
</P>
<!-- ####################################################### -->
<HR>
<H1>Contents</H1>
<UL>
<LI><A HREF="#2">The Standard C++ header files</A>
<LI><A HREF="#3">Thread-safety</A>
<LI><A HREF="#4"><TT><foo></TT> vs <TT><foo.h></TT></A>
<LI><A HREF="porting-howto.html">Porting-howto</A>
</UL>
<HR>
<!-- ####################################################### -->
<H2><A NAME="2">The Standard C++ header files</A></H2>
<P>The Standard C++ Library specifies 50 header files that must be
available to all hosted implementations. Actually, the word
"files" is a misnomer, since the contents of the headers
don't necessarily have to be in any kind of external file. The
only rule is that when you <TT>#include</TT> a certain header, the
contents of that header, as defined by the Standard, become
available to you, no matter how.
</P>
<P>The names of the headers can be easily seen in
<A HREF="headers_cc.txt"><TT>testsuite/17_intro/headers.cc</TT></A>,
which is a small testbed we use to make certain that the headers
all compile and run.
</P>
<HR>
<H2><A NAME="3">Thread-safety</A></H2>
<P>This is a thorny issue that gets brought up on the libstdc++-v3
and gcc mailing lists on a regular basis (probably by a cron job).
This entry will mention a very little bit about the general MT
issues with libstdc++. The latest status and quick notes will be
in FAQ 5.6. Some discussion about thread-safe containers will be
in section 6.8 (the HOWTOs on containers). This section only applies
when gcc and libstdc++-v3 were configured with --enable-threads.
</P>
<P>The libstdc++ code (all of it, not just the containers) has been
designed so that thread-safety will be easily possible. The first
(!) problem is finding a <EM>fast</EM> method of implementation
portable to all platforms. A minor problem that pops up every so
often is different interpretations of what "thread-safe"
means for a library (not a general program). We currently use the
<A HREF="http://www.sgi.com/tech/stl/thread_safety.html">same
definition that SGI</A> uses for their STL subset.
<EM>Please see the many cautions given in HOWTOs on containers.</EM>
</P>
<P>
Here is another attempt at explaining the dangers of using the
STL with threading support without understanding some important
details. The STL implementation is currently configured to use
the high-speed caching memory allocator. If you absolutely
think you must change this on a global basis for your platform
to support multi-threading, then please consult all commentary
in include/bits/c++config and the HOWTOs on containers. Be
fully aware that you may change the external or internal ABI of
libstdc++-v3 when you provide -D__USE_MALLOC on the command line
or make a change to that configuration file.
</P>
<P>
If you don't like caches of objects being retained inside the
STL, then you might be tempted to define __USE_MALLOC either on
the command line or by rebuilding c++config.h. Please note,
once you define __USE_MALLOC, only the malloc allocator is
visible to application code (i.e. the typically higher-speed
allocator is not even available in this configuration). There
is a better way: It is possible to force the malloc-based
allocator on a per-case-basis for some application code even
when the above macro symbol is not defined. The author of this
comment believes that is a better way to tune an application for
high-speed using this implementation of the STL. Here is one
possible example displaying the forcing of the malloc-based
allocator over the typically higher-speed default allocator:
std::list <void*, std::malloc_alloc> my_malloc_based_list;
</P>
<P>A recent journal article has described "atomic integer
operations," which would allow us to, well, perform updates
on integers atomically, and without requiring an explicit mutex
lock. This appears promising, but the major difficulty is that
these operations "may not be available on all systems, and
if they are, may have different interfaces." [quoting from
mailing list messages]
</P>
<P>Here is a small link farm to threads (no pun) in the mail archives
that discuss the threading problem. Each link is to the first
relevent message in the thread; from there you can use
"Thread Next" to move down the thread. This farm is in
latest-to-oldest order.
<UL>
<LI><A HREF="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00384.html">
inspired this most recent updating of issues with threading
and the SGI STL library. It also contains some example
POSIX-multithreaded STL code.</A>
<LI> <A HREF="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00136.html">
an early analysis of why __USE_MALLOC should be disable for
the 3.0 release of libstdc++.</A>
</UL>
<BR>
Here are discussions that took place before the current snapshot;
they are still relevant and instructive.
<BR>
<UL>
<LI>One way of preventing memory leaks by the old default memory
allocator in multithreaded code is
<A HREF="http://gcc.gnu.org/ml/gcc/1999-11n/msg00431.html">discussed here</A>.
<LI><A HREF="http://gcc.gnu.org/ml/libstdc++/1999-q3/msg00167.html">This thread
concerns strings</A>.
<LI><A HREF="http://gcc.gnu.org/ml/libstdc++/1999-q2/msg00339.html">So does this
one</A>. This initial message also refers to another
thread in the GCC mailing list...
<LI><A HREF="http://gcc.gnu.org/ml/gcc/1999-06n/msg00680.html">which is here</A>,
and goes on for some time. Ironically, the initial message
in this thread also mentions another threading thread...
<LI><A HREF="http://gcc.gnu.org/ml/gcc-bugs/1999-04n/msg00777.html">beginning here</A>,
and talking about pthreads. (Note that a much more recent
message from the first thread in this list notes that
<A HREF="http://gcc.gnu.org/ml/libstdc++/1999-q3/msg00176.html">pthreads
should not be used as a starting point</A> for making
libstdc++ threadsafe.)
<LI><A HREF="http://gcc.gnu.org/ml/libstdc++/1999-q2/msg00168.html">This
message</A>,
<A HREF="http://gcc.gnu.org/ml/libstdc++/1999-q2/msg00159.html">this one</A>,
and <A HREF="http://gcc.gnu.org/ml/libstdc++/1999-q2/msg00156.html">this one</A>
are the tops of related threads (all within the same time
period) discussing threading and the IO library. Much of it
is dealing with the C library, but C++ is included as well.
</UL>
</P>
<P>This section will be updated as new and interesting issues come
to light.
</P>
<P>Return <A HREF="#top">to top of page</A> or
<A HREF="../faq/index.html">to the FAQ</A>.
</P>
<HR>
<H2><A NAME="4"><TT><foo></TT> vs <TT><foo.h></TT></A></H2>
<P>The new-style headers are fully supported in libstdc++-v3. The compiler
itself fully supports namespaces, including <TT>std::</TT>.
</P>
<P>For those of you new to ISO C++98, no, that isn't a typo, the headers
really have new names. Marshall Cline's C++ FAQ Lite has a good
explanation in
<A HREF="http://www.cerfnet.com/~mpcline/On-Line-C++-FAQ/coding-standards.html#[25.4]">item [25.4]</A>.
</P>
<P>Return <A HREF="#top">to top of page</A> or
<A HREF="../faq/index.html">to the FAQ</A>.
</P>
<!-- ####################################################### -->
<HR>
<P CLASS="fineprint"><EM>
Comments and suggestions are welcome, and may be sent to
<A HREF="mailto:libstdc++@gcc.gnu.org">the mailing list</A>.
<BR> $Id: howto.html,v 1.1.4.3 2001/05/31 02:48:49 ljrittle Exp $
</EM></P>
</BODY>
</HTML>
|
