Are method call statements executed synchronously, in the order in which they are written?

Question

For example:

void Function1()
{
  Function2();
  Function3();
}

Will Function3 be guaranteed to wait until Function2 is done processing each and every time Function1 is called?

Answer 1

YES. Function3() waits untill unless Function2() execution is Completed.

if you want to invoke them independently you can use Multi-Threading concept.

EDIT: as suggested in Comments using Task is much better than Thread as it is a higher level concept.

Task Vs Thread

Try This to invoke them Independently:

using System.Threading.Tasks;

static void Main(String[] args)
        { 
            Task t1 = new Task(Function2);
            Task t2 = new Task(Function3);
            t1.Start();
            t2.Start();
        }

here we can not guarantee how the execution flow goes on.because they runindependently.

Answer 2

It's not completely clear to me what do you mean by “is done processing”.

But Function3() will be called only after Function2() returns, that's the whole idea behind imperative programming and basic C# is an imperative language.

Answer 3

Strictly speaking no. Modern CPUs, in order to improve performance, do tons and tons of optimizations under the hood. They execute things in parallel, leverage branch prediction, pipelining, etc. such that they can actually start, or even complete, operations that are supposed to happen after something that isn't actually done yet.

However, you don't need to worry about that. Great pains are taken to hide these implementation details from you. While those operations may not actually take place in the given order, it is impossible for you to ever observe the fact that they are out of order. In other words, you can always be sure that the resulting state of the computer after executing that code will be whatever it would be if the statements were executed in order. If the processor chooses to execute them out of order it will never result in a program that functions differently.

Of course, as said in the comments, this only applies to the execution of a single thread. When you have multiple threads executing there are very few guarantees about the observed order of execution of each operation.

Answer 4

The C# language specification says this:

3.10 Execution Order

Execution of a C# program proceeds such that the side effects of each executing thread are preserved at critical execution points. A side effect is defined as a read or write of a volatile field, a write to a non-volatile variable, a write to an external resource, and the throwing of an exception. The critical execution points at which the order of these side effects must be preserved are references to volatile fields (§10.5.3), lock statements (§8.12), and thread creation and termination. The execution environment is free to change the order of execution of a C# program, subject to the following constraints:

• Data dependence is preserved within a thread of execution. That is, the value of each variable is computed as if all statements in the thread were executed in original program order.
• Initialization ordering rules are preserved (§10.5.4 and §10.5.5).
• The ordering of side effects is preserved with respect to volatile reads and writes (§10.5.3). Additionally, the execution environment need not evaluate part of an expression if it can deduce that that expression’s value is not used and that no needed side effects are produced (including any caused by calling a method or accessing a volatile field). When program execution is interrupted by an asynchronous event (such as an exception thrown by another thread), it is not guaranteed that the observable side effects are visible in the original program order.

So I take this to mean that if the compiler or jitter can prove that your two function calls can be re-ordered, or even skipped, then the compiler is free to do so. In practice I believe that the compiler or jitter will not perform an optimisation like that on your code, and that your function calls will execute synchronously. On top of that the CPU is perfectly free to re-order execution for optimisation reasons, and will do so. Of course, it won't re-order execution in a way that changes the observable output.

In any case it is somewhat moot because whenever a language specification or CPU architecture allows re-ordering, it is only allowed if it makes no difference to the meaning of your program. So, you cannot come to any harm by having a mental model that says that statements are executed synchronously and in order. If the compiler and/or CPU chooses to re-order it will do so in a way that won't affect the outcome of your program.