Re: C++ Threads, what's the status quo?
Edward Rosten wrote:
Mirek Fidler wrote:
Shared y;
Mutex y_lock;
void fn() {
y_lock.Lock();
y = 10;
y_lock.Unlock();
}
nothing in C++ standard prevents C++ compiler to generate machine code
equivalent to
[snip reordering]
It looks like from this that y is global. If Lock() and Unlock() depend
on y, then the compiler couldn't reorder the bits of Lock() an Unlock()
depending on y.
But since they don't, the reordering is legal.
If the code for Lock() and Unlock() is not visible (eg
in a different translational unit), then how can the compiler reorder
the function calls?
What do you mean by "not visible"? The compiler is allowed to
analyse code in any way it wants. There's no such thing as "not
visible" code.
In practice, of course, the compiler will eventually get down to
a system request, and it will NOT be able to analyse the object
code of the OS to determine what it does. But such functions
make up a closed, finite set, with "well known" semantics, and
all of the necessary knowledge can be built into the compiler.
(I once used a compiler where this was the case; it regularly
kept updated global data in registers accross calls to library
functions.)
Note, I'm not claiming that threading is defined. I'm just disputing
this one particular example.
It's rather stretched, in that any compiler intelligent enough
to be able to know that Mutex::Lock() (and ultimately,
pthread_mutex_lock or its equivalent) didn't depend on nor
modify y would also be intelligent enough to know that
pthread_mutex_lock is a special function, which ensures
synchronization. So it would either complain (if compiling
single threaded code) or do the right thing (if compiling
multi-threaded code). The point remains that you are counting
on specific guarantees from the compiler.
You could probably construct it more carefully, eg by saying
that y not visible outside the translational unit, and &y is
never assigned to a pointer of Shared* which is visible
outside the translational unit.
Of course, that does make the example more realistic:
int fn()
{
// The two initializations are static, so
// no synchronization problems can occur.
static pthread_mutex_t
m = PTHREAD_MUTEX_INIT ;
static int i = 0 ;
pthread_mutex_lock( &m ) ;
++ i ;
int result = i ;
pthread_mutex_unlock( &m ) ;
return result ;
}
It doesn't take much intelligence on the part of the compiler to
determine that neither pthread_mutex_lock nor
pthread_mutex_unlock can depend on nor modify i; a reasonable
compiler might easily recognize that if it moves the ++i into
the return statement (and thus after the call to
pthread_mutex_unlock), it can do away with the intermediate
variable result completely.
I think you've found a case that is not only theoretically
possible, but actually likely to occur in practice. (In fact,
the above is fully conformant Posix C, and the Posix standard
makes the necessary guarantees for it to work. In C, on a Posix
based machine.)
--
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! ]