

Understanding Why Multithreaded Programming Is Hard - comatose_kid
http://ridiculousfish.com/blog/archives/2007/02/17/barrier/

======
gaius
I would argue that concurrent programming _is_ something new. If you have 2
processors, then the worst thing that can happen is you get 50% of the
machine's power per application - and if you have other processes running,
they can use the other processor. In practice, on a dual-processor machine,
you can completely ignore concurrency and often still get excellent
performance for the majority of users, just by letting the OS worry about it
for you. Particularly in the case where there is one long-running task in the
background and one interactive task in the foreground, the user will get the
best experience possible with no extra effort on the programmer.

The difference now is that with 32-cores (on the Sun T2000 for example) or
more, unless you have a very easily partitioned workload (e.g. serving simple
web pages), if you don't think about concurrency up front, your app will suck.
With 32 cores, naive approaches to locking will rapidly drag performance into
the mud. Working on massively multicore kit _if you need a single task to
dominate the system_ is a hard problem. Things are about to get interesting...

