Paul Butcher

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

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.

About Paul

Paul is an author and veteran of several technology startups. Most recently, he was Chief Software Architect at SwiftKey, the best-selling input method for Android devices.

His most recent book is "Seven Concurrent Models in Seven Weeks: When Threads Unravel" published by The Pragmatic Bookshelf.

He's currently consulting for a number of early-stage startups, helping them lay technical groundwork.

Twitter: @paulrabutcher

Back to conference page