Techniques for controlling program order of execution

Question

I'm wrestling with the concept of code "order of execution" and so far my research has come up short. I'm not sure if I'm phrasing it incorrectly, it's possible there is a more appropriate term for the concept. I'd appreciate it if someone could shed some light on my various stumbling blocks below.

I understand that if you call one method after another:

[self generateGrid1];
[self generateGrid2];

Both methods are run, but generateGrid1 doesn't necessarily wait for generateGrid2. But what if I need it to? Say generateGrid1 does some complex calculations (that take an unknown amount of time) and populate an array that generateGrid2 uses for it's calculations? This needs to be done every time an event is fired, it's not just a one time initialization.

I need a way to call methods sequentially, but have some methods wait for others. I've looked into call backs, but the concept is always married to delegates in all the examples I've seen.

I'm also not sure when to make the determinate that I can't reasonably expect a line of code to be parsed in time for it to be used. For example:

int myVar = [self complexFloatCalculation];
if (myVar <= 10.0f) {} else {} 

How do I determine if something will take long enough to implement checks for "Is this other thing done before I start my thing". Just trial and error?

Or maybe I'm passing a method as parameter of another method? Does it wait for the arguments to be evaluated before executing the method?

[self getNameForValue:[self getIntValue]];

Answer 1

I understand that if you call one method after another:

[self generateGrid1];
[self generateGrid2];

Both methods are run, but generateGrid1 doesn't necessarily wait for generateGrid2. But what if I need it to?

False. generateGrid1 will run, and then generateGrid2 will run. This sequential execution is the very basis of procedural languages.

Technically, the compiler is allowed to rearrange statements, but only if the end result would be provably indistinguishable from the original. For example, look at the following code:

int x = 3;
int y = 4;

x = x + 6;
y = y - 1;

int z = x + y;
printf("z is %d", z);

It really doesn't matter whether the x+6 or the y-1 line happens first; the code as written does not make use of either of the intermediate values other than to calculate z, and that can happen in either order. So if the compiler can for some reason generate more efficient code by rearranging those lines, it is allowed to do so.

You'd never be able to see the effects of such rearranging, though, because as soon as you try to use one of those intermediate values (say, to log it), the compiler will recognize that the value is being used, and get rid of the optimization that would break your logging.

So really, the compiler is not required to execute your code in the order provided; it is only required to generate code that is functionally identical to the code you provided. This means that you actually can see the effects of these kinds of optimizations if you attach a debugger to a program that was compiled with optimizations in place. This leads to all sorts of confusing things, because the source code the debugger is tracking does not necessarily match up line-for-line with the code the compiled code the compiler generated. This is why optimizations are almost always turned off for debug builds of a program.

Anyway, the point is that the compiler can only do these sorts of tricks when it can prove that there will be no effect. Objective-c method calls are dynamically bound, meaning that the compiler has absolutely no guarantee about what will actually happen at runtime when that method is called. Since the compiler can't make any guarantees about what will happen, the compiler will never reorder Objective-C method calls. But again, this just falls back to the same principle I stated earlier: the compiler may change order of execution, but only if it is completely imperceptible to the user.

In other words, don't worry about it. Your code will always run top-to-bottom, each statement waiting for the one before it to complete.