Quote:
Originally Posted by Smiling Spectre
And (guessing) as WinXP tries to "parallel" multithreading processes - when it's must be not - it crashes game.
|
Threads are parallel by definition and are meant to be so. As you say and I said earlier, the only way a program can behave any different in this context is if it creates threads, the OS won't do it unsolicited, it doesn't happen on its own, there are particular
API calls for it. The problem must be that the Dark Engine had bugs, but they happened to be masked in single-core computers.
Each thread decides when to release its core (or whole CPU in single cores without hyper-threading) for other waiting threads; if it doesn't, it will happen to continue running before the rest of threads in time.
But this isn't a feature of the code, and the only benefit of creating threads is to have them run in parallel if possible. If you want code to run in sequence, creating threads is just overhead, and of course it won't run in sequence unless the computer happens to be single-core without hyper-threading. And of course making on purpose a program with multiple threads, that don't release control at least for time slicing in single cores, and then even making the program so that it won't work with multiple cores when parallelism does appear, would be as stupid as it gets.
I'd guess the multi-threading in the Dark Engine was a commendable feature, perhaps thinking in the future, but as its o often happens with games, the engine was released with bugs still outstanding. The problem with parallelization is that sooner or later you need to synchronize everything back, and this is hard and prone to error. This bug must have been considered non-fatal because at that time there was no multi-threading hardware.