for( i = 0; i < 10; i++ ) {
inc_x();
inc_y(); // executed after inc_x(), but why wait?
// why not execute inc_y() in a separate thread?
// So, is this 'automatic threading' been done before?
// Is it even possible?
}
return get_x();
}
Name:
Anonymous2012-08-07 16:17
Not really. You would have to be 100% inc_y() doesn't depend on any state which will be mutated by inc_x(), which is impossible.
Anything is be possible here, you're incrementing two uninitialized variables.
Name:
Anonymous2012-08-07 17:43
javascript does this
Name:
Anonymous2012-08-07 17:59
Your compiler optimized the code in a way that made it so the calls are done in reverse order (I'm surprised the calls are made at all, you must not be optimizing it to the fullest), this kind of optimization is possible because the two symbols, x and y are not dependant of each other in that part of the code and are not marked volatile.
>>6
Optimizing it to the fullest would be not producing any output. The compiler can do anything once it finds undefined behavior, including just not doing anything.
>>1
The implementation has to behave ``as if'' they happened in order they would on the abstract machine. If there's no way for the program to ``observe'' a discrepancy without resorting to undefined behavior, they can take place simultaneously. >>4
Global/static variables in C are initialized to zero. Nice tryoll though.
Kind of similar to your example is asynchronous I/O.
>>2
Haskell gets around this by forcing you to mark any state as such with a monad, which lets it process things in whatever order it wants. It doesn't matter because there's no state.