Re: C++ Threads, what's the status quo?
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. 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.
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.
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. ("Basic" thread safety, the most useful level in general;
should be the default for all sensible C++ code.)
Higher up the chain is the "strong" thread safety, where instances are
writable from multiple threads without external synchronization.
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.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]