Order of operation on multi core hardware

[sockman]

Hello,
On a multi-core machine, am I guaranteed to have my code executed in the precise order it was written?
Cheers,
BJW

[nuzzle]

Yes, unless you make active use of multithreading language constructs there will only be one thread of execution also on a multicore computer.

[D_Drmmr]

Hello,
On a multi-core machine, am I guaranteed to have my code executed in the precise order it was written?
Cheers,
BJW

No, you never are. The computer doesn't execute your code, it executes binary instructions. Your code is translated into these instructions by the compiler and linker. The C++ standard only mandates that the observable behavior of the program corresponds with your code. The compiler is free to make optimizations as long as the observable behavior remains the same. This is particularly the case for return value optimization and copy elision, which implies that you are never guaranteed that a certain exact number of copies of an object is made.

The C++ standard implicitly assumes single-threaded execution, so if you use multiple threads in your program, you will need to provide synchronization between variables that are shared by multiple threads, where at least one thread writes to the variable.
Whether the program is executed on a single or multi-core machine makes no difference.

[JohnW@Wessex]

Hello,
On a multi-core machine, am I guaranteed to have my code executed in the precise order it was written?

You can't rely on that even on a single core.
For example, say you were to set a flag in a function to indicate to another thread that you had completed some action. Without a memory barrier, the compiler would be free to move the flag setting code to anywhere within the function, if moving it has no effect on the outcome of that function. Even marking the variable 'volatile' cannot guarantee this.

e.g.

bool done = false;

void Function()
{
    // Do some processing.
    ...

   // Flag as 'done'
   done = true; // You cannot guarantee that this will happen last, after optimisation.
}

The compiler may look at the code above and decide it is more optimal to set the flag at the beginning of the function.

[nuzzle]

No, you never are. The computer doesn't execute your code, it executes binary instructions.

That's bullshit. The execution order is defined by the programming language alone. A program will run as written. Multicore hardware or not has no influence on that.

[nuzzle]

You can't rely on that even on a single core.

That's bullshit. The execution order is defined by the programming language alone. A program will run as written. Multicore hardware or not has no influence on that.

[D_Drmmr]

That's bullshit. The execution order is defined by the programming language alone. A program will run as written. Multicore or not has no influence on that.

If it's defined by the programming language, then please quote the section of the standard that states this.

[JohnW@Wessex]

Here's a quote from Herb Sutter about reordering of reads and writes.

Second, what about nearby ordinary reads and writes -- can those still be reordered around unoptimizable reads and writes? Today, there is no practical portable answer because C/C++ compiler implementations vary widely and aren't likely to converge anytime soon. For example, one interpretation of the C++ Standard holds that ordinary reads can move freely in either direction across a C/C++ volatile read or write, but that an ordinary write cannot move at all across a C/C++ volatile read or write -- which would make C/C++ volatile both less restrictive and more restrictive, respectively, than an ordered atomic. Some compiler vendors support that interpretation; others don't optimize across volatile reads or writes at all; and still others have their own preferred semantics.

[JohnW@Wessex]

That's bullshit. The execution order is defined by the programming language alone. A program will run as written.

int a;
int b;
int c;

void Function()
{
    a = 0;
    b = 1;
    c = 2;

    // Some other stuff.
}

Are you really saying that you believe a, b & c are guaranteed to be initialised in that order? Everything I've read about compiler optimisations and CPU instruction reordering imply otherwise.

[nuzzle]

If it's defined by the programming language, then please quote the section of the standard that states this.

What a silly request.

A programming language defines an abstract computer and how it behaves is defined by the standard as a whole. But if you need a place to start you can have a look at 1.9 Program execution.

http://www.open-std.org/jtc1/sc22/wg...2010/n3092.pdf

[nuzzle]

Are you really saying that you believe a, b & c are guaranteed to be initialised in that order? Everything I've read about compiler optimisations and CPU instruction reordering imply otherwise.

You're confusing the language with implementations of the language.

The language defines an abstract computer and it will execute a program written in that language exactly as the standard specifies.

Physical implementations of the abstract computer, such as compilers, interpreters and various hardware cannot change that. If they do they're not conformant with the language standard.

[JohnW@Wessex]

You're confusing the language with implementations of the language.

The OP asked

On a multi-core machine, am I guaranteed to have my code executed in the precise order it was written?

He is talking about a real implementation of C++ code on a real machine. Real compilers can re-order reads and writes. Real CPUs can execute 'out of order'.
If you don't take this into account when writing multi-threaded / multi-core applications then you are heading for big trouble.

[D_Drmmr]

A programming language defines an abstract computer and how it behaves is defined by the standard as a whole.

Here, section 1.9.1

This International Standard places no requirement on the structure of conforming implementations. In particular, they need not copy or emulate the structure of the abstract machine. Rather, conforming implementations are required to emulate (only) the observable behavior of the abstract machine as explained below.

Next time, please take one minute to investigate before calling something bullshit or otherwise, provide some well-funded arguments.

The language defines an abstract computer and it will execute a program written in that language exactly as the standard specifies.

Physical implementations of the abstract computer, such as compilers, interpreters and various hardware cannot change that. If they do they're not conformant with the language standard.

Let's consider a practical example that just popped up in another thread. We know the double check locking pattern for the implementation of a singleton is broken. However, this cannot be explained in terms of the code itself, only in terms of the hardware. So following your logic, this would mean that modern PC's are not conformant with C++ (whatever that should mean, I never heard of such a notion and don't think it makes any sense). That makes your point moot, because you cannot execute a program on an abstract machine.

[VladimirF]

That's bullshit. The execution order is defined by the programming language alone. A program will run as written.

That is a pretty strong language for such a weak statement...

Multicore hardware or not has no influence on that.

Well, this IS correct, as regardless of the number of cores the order is not guaranteed

[laserlight]

Here, section 1.9.1

Also, refer to:

This provision is sometimes called the "as-if" rule, because an implementation is free to disregard any requirement of this International Standard as long as the result is as if the requirement had been obeyed, as far as can be determined from the observable behavior of the program. For instance, an actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no side effects affecting the observable behavior of the program are produced.