Re: C++ Threads, what's the status quo?
Le Chaud Lapin wrote:
Jeff Koftinoff wrote:
Le Chaud Lapin wrote:
The problem is not optimization; the problem is the C++ specification
does not prohibit the standards conformant compiler to optimize your
multithreaded code into oblivion.
#include <string>
void f( const std::string &s )
{
std::string my_copy(s);
// do anything or nothing with my_copy here
}
std::string my_label( "testing" );
void thread1()
{
while(1)
{
f( my_label );
}
}
void thread2()
{
while(1)
{
f( my_label );
}
}
Jeff, I do not mean to offend you, but this example is precisely the
reason I made the statements I made before.
my_label is a global variable. The copying operation is an active
operation possibly involving modification of state.
Since when? By definition, copying doesn't change the state of
an object. (In fact, depending on the implementation, it may
change some internal state. But in a well written library, this
shouldn't be a concern of the client.)
There is a _gross_
difference in mentalities going on here.
There are two different points of views coming from two different
groups of programmers:
Group 1 says, "f takes a const & argument, and therefore does not
modify it, so technically, it is const, and therefore it should be
thread safe for read operations"
That's not quite the argument---the language allows f to use a
const_cast to modify the original object here. The argument is
that f has a contract not to modify the object, and so doesn't.
Group 2 says, "Not only do we think that it is presumptive to imply
that C++ should 'honor' 'read-only' access to global variables, we do
not recognize this point of view."
Note that I could take your example, make a large const global object
with 100 data members, all declared mutable, invoke some operations on
it from two threads and say, "Mon Dieu..!!!" my const global variable
with all those mutable members did not withstand simultaneous access by
multiple threads!!!
No one ever said that a const global object should be "thread safe".
Posix does (but Posix doesn't talk about C++ objects). The
current wording in the draft C++ standard does.
In the end, of course, thread safety is a question of contract.
If object X guarantees that I can do operation y from multiple
threads without synchronization, then if I do so, and there is a
problem, it is an error in the code for object X. If object X
doesn't make this guarantee, then it is an error in my code.
Normally, the default guarantee, at least for those of us
working in Posix environments, is that I do not need
synchronization as long as there is no modification to the
object state, with "object state" only referring to visible
state, and not "behind the scenes" traficking.
And of course, there is a fundamental presumption that code is
not thread-safe, i.e. that it makes no guarantee whatsoever,
unless it is specifically stated that it is. (For most objects,
a phrase like "the usual thread-safety guarantees apply" is
sufficient. Or there may be a library wide statement, i.e. as
there is with Posix, and almost certainly will be in C++; such
library wide statements may specify exceptions, of course.)
--
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! ]