4 ms·
Well, no, we don't need to accept that cost, it's just a constraint for a concurrency model to choose, i.e. maximizing locality. Apart from that another big one
by zzzcpan 7y ago
Well, no, we don't need to accept that cost, it's just a constraint for a concurrency model to choose, i.e. maximizing locality. Apart from that another big one for massively multicore systems is minimizing cross-core synchronization. You can meet both, just not with threads as your programming model.
- bullen 7y agoSo what would you use instead of threads? How do you mean "maximizing locality"? My intuition is that the reason Java can be concurrent is that it uses a VM that incurs cache misses on all IO. So in practice you can't have both. In C you can try to use locks to achieve something but for a long time of development you will be in dead-lock and race condition hell.