Re: C++ Threads, what's the status quo?
Peter Dimov wrote:
Le Chaud Lapin wrote:
In any case, I certainly agree that
1. C++ programmers want to write multi-threading applications
2. Some _libraries_ are not thread-safe
3. I would be nice to have thread-safe libraries for C++
You use "thread safe" without explaining it. There are various levels
of thread safety.
I agree with the point you are making, but I disagree with the
idea of "levels of thread safety". In the end, there are only
two: a component specifies its contracts with regards to
threads, or it doesn't. If it doesn't, a program which uses
that component is not thread safe. Period. If it does, a
program which uses the component is thread safe if and only if
it fulfills its end of the contract.
Obviously, of course, the contract can shift more or less of the
work off to the client code. But a compiler which requires
external synchronization for adding two int's is thread safe, if
that is the documented contract. (It's not very usable, of of
course, but that's a different issue.)
One extreme is "no thread safety", when you absolutely can't
use the component from more than one thread at a time. Some
std::maps in the old days had that feature due to hidden
shared globals.
Typical implementations, at least on Unix platforms, of
functions like localtime and strtok still have this
characteristic.
The next step is that separate instances are usable without
synchronization, but a single instance is not, even when not modified.
Your containers sit at this level because of their embedded iterators.
This is also the official guarantee of components in libstdc++,
used with g++. (In practice, most components give the SGI
guarantee.)
Next up, we have the modern STL, where it's possible to read the same
instance from multiple threads. This is also the thread safety level
for all basic types, both de facto and as specified by the POSIX
standard.
De facto is very uncertain. I can think of a few cases where it
might not be automatic (e.g.: objects in a shared object, when
accessed from a thread other than the one that loaded it). De
facto isn't a contract, and you don't know when it applies, and
when not.
And the Posix guarantee isn't limited to basic types; it applies
to any time that is accessed in a single operation. (Formally,
Posix speaks of "a memory location", without defining what is
meant by "memory location". Intuitively, given:
struct S1
{
int b1 : 1 ;
int b2 : 1 ;
} ;
struct S2 { S1 x; S1 y ; } s ;
I would expect that s.x and s.y correspond to different memory
locations, but x.b1 and x.b2 don't. The last time I talked with
anyone on the committee, too, it seemed that this was the
direction C++ was going. But it does introduce added
constraints on the compiler, at least on some hardware.
("Basic" thread safety, the most useful level in general;
should be the default for all sensible C++ code.)
That is, of course, a personal opinion (which I happen to
share). At least at one time, the authors of the g++ library
felt differently, and made a weaker guarantee.
Higher up the chain is the "strong" thread safety, where instances are
writable from multiple threads without external synchronization.
Which is rarely useful. And not always even possible. How
could you provide this guarantee with std::vector, for example,
so that I wouldn't need a lock for:
std::vector< int > v ; // Shared instance....
v[ 0 ] = 42 ;
I made a distinction between the language proper and the libraries. I
was trying to emphasize that I see very little wrong with C++, the
language proper.
There is nothing wrong with the language. The standard just doesn't
guarantee any specific behavior for multithreaded code. (Keep in mind
that some compiler optimizations are undetectable in single-threaded
code but not in MT.) The language itself will not change. The new
standard will simply specify its MT behavior.
The language probably will have a few minor extensions as well.
I wouldn't be surprised if there were support for thread local
variables, for example, and the obvious way to implement that is
a new storage class. But by far the greatest impact will be
things like replacing sequence points with a concept which works
for multiple threads, and defining when you need
synchronization, and when you don't (things like modifying two
different bit fields, or two different char's from the same
array or struct, from different threads).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]