Re: std::string bad design????
Le Chaud Lapin wrote:
Mirek Fidler wrote:
If you are going multithreaded, you must serialize access to
containers, end of story. (Of course, you could also consider
containers with internal locking, but that does not work well).
What I find odd is that you, Mirek, are the first person in, perhaps,
my last 10-15 posts about multi-threading to explicitly state this,
both in this thread and concurrent threads (no pun intended) .
It is incredibly perplexing to me that people keep saying, "But...If
Thread A and Thread B access the same global static variable of a
[insert name of your favorite C++ class here] at the same time, then
there will be a contention problem."
Of course!!!!!!!
Who has said otherwise?
The problem is that you don't know what the classes do. You use
an std::map, for example; how do you know that it doesn't use
static memory (e.g. in its allocators) in the implementation.
Unless std::map is thread-safe, you cannot use it in a
multithreaded application.
You might want to check
http://www.sgi.com/tech/stl/thread_safety.html; I'm pretty sure
that this corresponds to the thinking of the committee with
regards to how thread safety will be defined in the library.
(Except some special cases, like maybe std::cerr, and almost
certainly std::exit().)
Note that the implementation of std::basic_string in g++ does
not give this guarantee, although I think that the developpers
consider this an error (The combination of circumstances
necessary to encounter a problem is extremely unlikely to occur
in actual practice. But at least some of the developpers of g++
feel like I do: unless the probability is 0, it's an error.)
Note that in g++ pre 3.0, every single constructor of
std::basic_string modified global state. As did the
implementation of throw. Presumably, if you created the
necessary mutex, and never created a std::basic_string (nor
called a function which might do so---and do you know for sure which
functions in the standard library create temporary strings)
without first acquiring the mutex, and wrapped every throw/catch
with a mutex, your code might work. (Then again, it might not,
because there was no guarantee that nothing else used static
data.)
Unless a library is thread safe, it cannot be used in
multithreaded code. Note that just grabbing a mutex at the
start of every function, and releasing it at the end, is neither
necessary nor sufficient to make a library thread safe. To make
a library thread-safe, you must document the guarantees that are
given: thus, for example SGI (and everyone else) guarantees that
you can create two separate instances of std::vector in two
different threads, and use them, without external
synchronization.
And of course, the compiler must also make similar guarantees.
If you're working on Intel architecture, for example, the
compiler only has a very few registers to work with, and will
spill to memory if the expression is sufficiently complicated.
Every compiler I know spills to stack, but there is nothing in
the C++ standard to require this, and if the compiler spills to
static memory, you can end up with code which may or may not
work, depending on the level of optimization.
I would imagine that there is no computer science department at any
university in the world that does not teach this. There is no book on
operating system in the world that was written in say, the last 20
years, that does not teach this.
Why is it that so many experts and neari-experts find this utterly
obvious fact remarkable?
Why don't you read what the experts are saying, instead of
arguing against strawmen of your own creation.
I am not simply asking this question rhetorically. Please, if anyone
knows, tell me, so I can stop assuming that it is lack of experience
with multi-threading, which, IMO, would still not be an excuse.
Is it expectation that C++ will somehow develop some universally
applicable lock-free mechanism?
What, may I ask, gives you this idea? I've not even seen it
suggested.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, 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! ]