That's an oversimplified view.
E.g., let's say we write a massively multi-threaded shooter game. Each player is a separate thread, and we'll throw in a few extra threads for other stuff. What happens when I shoot at you? Actually all online multiplayer games work just like that, a thread (or several) on each machine connected and one more for the server that handles it all (including conflict resolution). Obviously the tasks that you assign to each thread have to be coherent but that's not computer related, in a factory you can have a thousand workers, each one performing a different task (like building something) and if the how and when it's not clearly defined it will end up being a complete mess anyway (an there are not computer to mess things up here).
multithreading has nothing to do with the actual number of cores, as you can create 20 different threads into a single core computer. Usually the operating system distributes and organizes your threads so you don't have to and it usually does a damn good job as some Sun servers are able (and have been able to do it for quite a time now) to run up to 64 simultaneus threads.
Multithreading is tricky and can lead to a lot of problems and headaches but, as CPU power is currently reaching its limits (or so it seems) multicore seems to be the only way to go so we better learn and start using it. I've developed multithreading applications and the number of threads doesn't matter so much, what does actually matters is the number of task in which you can subdivide the problem. In my case there where 4 fixed threads with 4 different concrete task and a variable number (configurable under app settings) of background workers wich will consume data generated by the other 4, so its not actually that difficult, for the standar programmer at leas, maybe OS guys will have to work harder but...
Slashdot Mirror
E.g., let's say we write a massively multi-threaded shooter game. Each player is a separate thread, and we'll throw in a few extra threads for other stuff. What happens when I shoot at you? Actually all online multiplayer games work just like that, a thread (or several) on each machine connected and one more for the server that handles it all (including conflict resolution). Obviously the tasks that you assign to each thread have to be coherent but that's not computer related, in a factory you can have a thousand workers, each one performing a different task (like building something) and if the how and when it's not clearly defined it will end up being a complete mess anyway (an there are not computer to mess things up here).
Nonsense,
...
multithreading has nothing to do with the actual number of cores, as you can create 20 different threads into a single core computer. Usually the operating system distributes and organizes your threads so you don't have to and it usually does a damn good job as some Sun servers are able (and have been able to do it for quite a time now) to run up to 64 simultaneus threads.
Multithreading is tricky and can lead to a lot of problems and headaches but, as CPU power is currently reaching its limits (or so it seems) multicore seems to be the only way to go so we better learn and start using it. I've developed multithreading applications and the number of threads doesn't matter so much, what does actually matters is the number of task in which you can subdivide the problem. In my case there where 4 fixed threads with 4 different concrete task and a variable number (configurable under app settings) of background workers wich will consume data generated by the other 4, so its not actually that difficult, for the standar programmer at leas, maybe OS guys will have to work harder but