Originally Posted by DuckieHo
Of course, but the point is that multithreading increase complexity exponentially. There are more possible states which leads to more possible test scenarios. Contention and state machine considerations are not issues with single-threaded processes.
I wasn't talking singlethreaded processes either. It's just a matter of identifying dependancies and the ability to split the tasks to be done into smaller problems and properly synchronize those identified dependancies. That's what I meant by a pre-emptive approach. Multithreaded servers by nature would be more complex as more threads (connections) are active, but in reality it's not more complex. Like said, it's a matter of identifying/designing dependancies around tasks such way to balance out synchronization with independant execution. But ah well, this goes a bit too far into detail.
The actual biggest problem with multithreading isn't skill, but the nature of the task one's trying to implement. Highly sequential processes by nature are difficult or impossible to multithread. Databases are an example where multithreading yields near maximum benefit. Games not so much as these are pretty much sequential in their execution. As said before, games manage to separate out audio, video and core execution into separate threads but that's where it ends for most games. Then indeed you have the CPU intensive games, but as the adjective suggests, these are worth to be multithreaded because there'll be sufficient independant load to make it worthwile.
Technology unfortunately doesn't change the problem, it only helps to an extent to ease dealing with the problem (Sequentiality, if that's even a word lol)