How do threads decide when to 'go'?
There are (at least) four reasons.


They do not start at the same time. Before the second executeEvery is even found by the interpreter, the first one may already have executed some steps!
You don't even know if the platform supports parallelism. So you can only expect one move to be computed after the other; you may be able to control the relative speed (see below).
The threads themselves don't have any control over this (on most machines).
Either a virtual or the actual machine runs a scheduler that decides which process or thread runs when. For the programmer, the only robust way to deal with this is by assuming non-determinism (i.e. arbitrary order).
wait(10) won't wait for exactly 10ms. Even active waiting can get you only so close to the exact time frame.


If you want to execute the updates simultaneously -- in the sense that both boxes make their $i$th move before they do their respective $(i+1)$th -- you will have to use means of synchronisation, e.g. a barrier.