Concurrency: It's Harder (and Easier) than you Think

Your software needs to leverage multiple cores, handle thousands of users and terabytes of data, and continue working in the face of both hardware and software failure. Concurrency and parallelism are the keys to this new world.

But writing multithreaded code is *hard*. Even harder than most people realise. Do you know how to avoid deadlock? Livelock? Do you know what the memory model says about when it’s safe for one thread to read changes made by another? Or why you shouldn’t call a foreign function while holding a lock? And threads and locks give you no help when it comes to distribution, fault-tolerance or exploiting data parallel architectures.

The good news is that there are other approaches, including actors, communicating sequential processes and functional programming, that avoid the pitfalls of threads and locks.

Talk objectives:

- To scare the audience: Threads and locks are much more difficult to use than most people realise. Chances are, unless you're a concurrency guru, your concurrent code is wrong in ways you don't understand.

- To show the way forward: It doesn't have to be this way, there are ways to safely exploit concurrency that avoid these pitfalls.

Target audience: Everyone who writes software. Concurrency is everywhere - even client-side web programming is going concurrent. So no matter what kind of software you write, it’s going to be an increasingly important aspect of what you do.