4 ms·
One good way to tackle is to use threads for hiding shared data. In a nutshell, instead of sharing variables between threads and protecting them by a lock, each
by Aegean 17y ago
One good way to tackle is to use threads for hiding shared data. In a nutshell, 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. The result is easy, deterministic concurrency, and many cores may be used this way. One of the founding goals of the Go language is also based on this idea.
- bad_user 17y ago> 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).