Re: What guarantees do I have on the order of execution?
Hi DeMarcus!
On Thursday, October 3, 2013 12:20:02 PM UTC-4, DeMarcus wrote:
Hi,
In a multithreaded environment (both pre- and post C++11), which of
these are guaranteed to protect the value?
First off, strictly speaking, prior to C++11, C++
(i.e., the C++ standard) was silent on threading
issues, so, strictly speaking, all bets are off,
in general. Of course, your particular pre-C++11
threading api, os, and compiler may work together
to give you reasonable guarantees.
My answers, below, will speak to C++11, but should
be applicable to any reasonable threading api and
thread-aware compiler.
int MyClass::getValue() const
{
SomeScopedMutex lock();
return someMemberValue;
}
Question to above: Will the value be copied to the return value before
the destructor of SomeScopedMutex?
Yes. For example, if someMemeberValue is not atomic
(say a long long), it will not be the case that some
other thread will be allowed to write to someMemberValue
while it is in the process of being copied to the function's
return value. (Assuming, of course, that SomeScopedMutex
is some sort of reasonable RAII mutex class.)
int MyClass::getValue() const
{
SomeScopedMutex lock();
int retVal = someMemberValue;
return retVal;
}
int MyClass::getValue() const
{
int retVal;
SomeScopedMutex lock();
retVal = someMemberValue;
return retVal;
}
Question to all above: Am I guaranteed that the compiler won't optimize
those to a malign order of execution?
Again, in both cases you're fine. The assignment
to retval and the return of retval are protected
by the instance of SomeScopedMutex. (But, again,
with the proviso, that the pre-C++11 standard is
silent on all of this, so pre-C++11, you are depending
on your compiler being "reasonable.")
Thanks,
Daniel
Happy Multi-Threaded Hacking!
K. Frank
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]