Re: C++ Threads, what's the status quo?
Jeff Koftinoff wrote:
Greg Herlihy wrote:
No, the compiler may possibly eliminate count++ (in some cases), but it
is not allowed to execute it before StMutex's constructor executes.
After all, there is a sequence point between the two statements:
"At certain specified points in the execution sequence called sequence
points, all side effects of previous evaluations shall be complete and
no side effects of subsequent evaluations shall have taken
place."[?1.9/7]
The above rule applies only to "actual code generated." The compiler is
not obligiated to generate code for every statement - statements that
have no effect on the observable state of the program can be
eliminated. But otherwise, unless the statement is eliminated, then it
must execute as ?1.9/7 requires - that is, in a specific order
relative to the program's other statements. Otherwise, if the compiler
could reorder sequence poitnts at will, it would not be possible to
write single-threaded C++ programs and be sure that they would run
correctly.
Thanks for the insight; This is fascinating to me... All of the CPU's
that I am writing code for has either vector processing or multiple
instruction units in parallel. The assembly code that the compilers
generate most definitely parallelize and re-order these kinds of
statements, especially if the objects that are created are small enough
to fit in a register and the compiler does dependency analysis of the
data.
Does this mean that these compilers that I am using are not compliant
to the c++ standard?
If an operation has no dependencies on other operations, then it is not
ordered "relative to the program's other statements" so there is no
order that needs to be observed. In the program I wrote, the operations
are dependent on earlier ones; executing them out of order would
execute a program different than the one I wrote.
If so, does that mean that the c++ standard dictates that VLIW cpu's
with parallel execution units can not be effectively, efficiently
utilized without violating the standard?
No, the C++ Standard doesn't impose any requirement on the on the
implementation except that a C++ program produce the expected results
as if it had executed the program exactly as it was written.
So either the program executes the statements in their current order or
it skips one or more of them. So for which ones does the compiler have
to generate code? The compiler is not allowed to optimize away StMutex.
Furthermore, since StMutex's constructor calls pthread_mutex_lock() - a
call which may or may not result in observable side effects, and its
destructor calls pthread_mutex_unlock() (which may or may not depend on
count's current value), the compiler must generate code for all three
statements that will execute in the order specified by the program.
However the original code does not specify what StMutex's constructor
did call... And the compiler most definitely can deduce that both
pthread_mutex_lock() and pthread_mutex_unlock() are not given the
address of count and therefore can not read or write it.
Not so, because count has external linkage; it is accessible from
anywhere in the program. So either of the external routines called may
make use of its value - for all the compiler knows. The function could
for example stream count's value to std::cout or assign it to a
variable declared volatile, either of which would require count's value
to be correct.
Even if count had internal linkage, there is the possibility that the
call to pthread_mutex_lock() would call another function which could
access count and which would proceed to manipulate its value. Note that
the affect of such a change need not be immediate: the compiler would
be hard pressed to prove that such a change will have no effect on any
aspect of the program's observable behavior in the future.
In summary, there are just too many things that can happen within a
function call for the compiler to be sure that it had anticipated every
eventuality and handled it correctly. The freedom that the compiler is
granted - to do anything it likes with a program's set of instructions,
is not the same as the freedom to let anything happen when the program
is run. So unless count has its expected value when
pthread_mutex_lock() is called, there is no way to be sure that count
will ever have the right value again, after the call returns.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]