Re:Multicore requires OS rework, Windows architect advises
by bad_user on Friday March 19, 2010 @02:49PM
(#1204923)
> instead of sharing variables between threads and protecting them by a lock, each thread has access to a portion of data, and they synchronously communicate
That's not enough.
If we are to believe Intel that we'll have processors with thousands of cores, then you have a new problem ... how are you going to keep all those cores busy (regardless of the actual number, from 32 to 20000)?
Another problem would be that you also want it to scale horizontally ... there's no reason why you'd want to know if another thread runs in the same process or on some other machine in China. All you care about is that you can spawn it, send a message to it and get some results.
Multiple techniques for concurrency will develop in parallel (which is a PITA since devs will need to have a lot of experience to choose), although I'm pretty sure that STM will be the most popular technique (although the handling of concurrency shouldn't be limited just to controlling access to RAM).
That's not enough.
If we are to believe Intel that we'll have processors with thousands of cores, then you have a new problem ... how are you going to keep all those cores busy (regardless of the actual number, from 32 to 20000)?
Another problem would be that you also want it to scale horizontally ... there's no reason why you'd want to know if another thread runs in the same process or on some other machine in China. All you care about is that you can spawn it, send a message to it and get some results.
Multiple techniques for concurrency will develop in parallel (which is a PITA since devs will need to have a lot of experience to choose), although I'm pretty sure that STM will be the most popular technique (although the handling of concurrency shouldn't be limited just to controlling access to RAM).