
The Problem with Threads (2006) [pdf] - amzans
https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
======
bullen
Another threads post another opportunity to discuss what I learned building a
joint (on the same memory) parallel app. server:
[http://github.com/tinspin/rupy](http://github.com/tinspin/rupy)

To fully use concurrency without monitors I think we need to accept the cost
of cache misses. When Java rewrote the memory model of the JVM to allow for
concurrent data structures they did something C/C++ still has not provided: a
platform where you actually can build something that scales on many threads
without causing more problems than it solves.

To me this has divided the programming word into two: Avoid cache misses or
use many threads. Pick one?!

~~~
zzzcpan
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
So 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.

