Re: volatile and sequence points in (GASP) multithreaded programs
On Jul 3, 1:10 am, Old Wolf <oldw...@inspire.net.nz> wrote:
On Jul 2, 9:20 pm, James Kanze <james.ka...@gmail.com> wrote:
On Jul 2, 1:03 am, Dave Rahardja
void foo(); // Defined in another compilation unit
bool flag;
while (!flag)
{
foo();
}
Forces the compiler to re-read flag at the head of each loop
iteration?
No.
Well, actually it causes undefined behaviour by
reading an uninitialized variable, so technically
the compiler is not forced to do anything :)
:-)
But supposing that 'flag' were initialized to false,
I think it does force the compiler to re-evaluate
flag because foo may change the value of flag, which
has external linkage.
First, of course, I see nothing in the above to suggest that
flag may have external linkage. But my point was really only
that the compiler is not required to re-evaluate the expression
per se; all that is required is that the observable behavior be
respected. In practice, a lot of compilers today optimize
beyond compilation units, and the compiler will be able to see
whether foo modifies flag or not. If foo doesn't modify flag,
the compiler is free to turn the loop into an endless loop, and
even if foo does modify flag, the compiler must only ensure that
the loop ends when it sets flag to true. Conceivably, for
example (although I don't know of any compiler which does so),
it could some how patch up the return address on the stack.
Note, it might not do a physical read of flag if
it optimises across translation units, but I think
the thrust of the question was: is the above code
always an infinite loop, or could the condition
fail eventually?
I'm not really sure what the thrust of the question was. The
subject line spoke of volatile and sequence points. At one
point, too the poster asked about threads. So I'm not too sure
what information he's really looking for: if threads are
involved, for example: volatile normally has no thread relevant
semantics, unless the compiler chooses to give it some, and
sequence points aren't defined with respect to threads.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34