Re: C++ Threads, what's the status quo?
Peter Dimov wrote:
Le Chaud Lapin wrote:
int x = 10; // Code corrected by Le Chaud Lapin
int thread1 ();
int thread2 ();
It's subtler than that. If you let the two threads read x without
changing it, do you expect problems?
If there is any potential for x to be written to in the program, yes,
otherwise, no.
Consider the similar example:
char x[] = "Test";
void thread1()
{
char a = x[0];
}
void thread2()
{
char b = x[0];
}
Do you expect problems here?
No.
Now replace the definition of x with:
std::string x( "Test" );
James Kanze argues that the code remains correct, and that g++ is in
error to not work. Before jumping to conclusions about his
understanding of the threading issues, you first need to understand
what he's saying. (I happen to disagree with him that the code is
correct. Either way, one of the goals of the future C++ standard is to
resolve these issues by specifying the thread safety level of the
standard library components.)
I see what you are saying here. And I know what James is saying. And
I think there is a disconnect in reasoning.
To take your example further, I could make a const global variable that
has a mutable member and still have the same problem:
struct Vending_Machine
{
mutable unsigned long int quaters_deposited;
///
} ;
const Vending_Machine out_of_order;
This example would not fool me. Anytime I see a global object, in a
multi-threading application, I know the implications of making
assumptions, and I do not mess around. I use a mutex.
It is my opinion that people who write multi-threaded applications on a
daily basis are in tune with the fact that global really does mean
global. This is why I was so puzzled before. It seems contradictory
(to me) that one could have so much experience with threading yet be
bother by these examples. In all fairness, another poster mentioned
CPU cache synchronization, which is valid, on some high-end systems,
but I did not broach that subject because I did not want this thread to
turn into an esoteric discussion on bus-locking, contention resolution,
etc. [There are some nice tricks that involve randomization that
helps, but are very boring to the programming community in general].
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++
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. I stated that, much of what the average programmer
wants by way of threading and synchronization can be implemented within
the context of the existing language, meaning, that part of the
language that is not the libraries. Obviously, I do not expect anyone
to use single-threaded libraries in a multi-threaded application and
have no problems.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]