[deathbob]

The print statements to debug was a constant in "Coders at Work" too. Also in that book I found interesting that everyone interviewed was asked what the most difficult thing they had to debug was, and almost all of them said something to do with concurrency.

[NickPollard]

That's not surprising though, if there's one thing I've had drummed into me throughout my education and career, it's that concurrency is /hard/. Particularly since it requires thinking about things in a completely different way to a lot of single-threaded programming.

[JoeAltmaier]

Yes, and its because programming languages actually provide almost nothing to help out here.

E.g. methods cannot be declared 'non-reentrant'. Data cannot be declared 'atomic'. Yes, you can hack together solutions using library methods etc. but the language doesn't help much.

We wrote an 'operating environment' for a major computer manufacturer once - a storage device they eventually cancelled (hardware was problematical). Programmers wrote objects that were each invoked single-threaded, passed workitem messages between services instead of directly calling. The environment managed message queues, handled all the threading and reentrancy invisibly.

The programming team loved it. They could write restartable, failoverable modules in this model without every dealing for an instant with concurrency explicitely.

[axod]

It's also completely avoidable.

Concurrency is only hard because it's a stupid thing to do - to give a bunch of instructions to the CPU and tell it to execute them in a random order.

[eru]

Why not, if you compiler proves that it's safe?

I don't even care in which order my single-threaded code gets executed (if it's in the right language).