If you’ve been hanging around a computer science department (or large chunks of industry) for the past couple of years you’ve probably heard all of the ruckus about parallel programming.  Thanks to the rise of multi-core chip architectures like the Intel core duo, we’re all going to have to learn how to program in parallel. (and no, I don’t mean alt-tabbing to your browser window)  This is definitely the “it” topic right now, motivating a lot of research and rethinking of the system stack.  To take a couple of acronymic examples that you might be familiar with: CUDA, OpenCL, Larrabee (GPGPU), the TRIPS project at UT Austin, Fortress, Chapel, software transactional memory, the pervasive parallelism project at Stanford, Apple’s grand central dispatch, deterministic parallelism research at UW…  (a list highly influenced by where I’ve been certainly)

One of the points I keep hearing in this trend frenzy is that “we” (i.e. computer science departments) are not doing enough to teach our students parallelism.  The problem that I see is that most computer scientists really don’t know that much about parallelism.  Should we be teaching students threads with locks and condition variables, like our operating systems classes are doing right now?  Should we be teaching them message passing?  Should we just expect them to declare atomic blocks and software transactional memory will magically take care of the rest?  Do they need to know about cache coherency mechanisms? asynchronous protocols? Paxos?  Should we begin by talking about different machine architectures or by talking about different semantic models?

One constant everyone seems to agree on is that you have to explain threads and mutexes very early on.  So, when someone says “we need to start teaching students about parallelism starting in their first year,” do they mean to say we should teach freshmen computer science students about threads and mutexes?

This seems like a bad idea to me.  In fact, I just recently read a very interesting slide deck for a talk John Ousterhout gave at the 1996 USENIX conference, titled “Why Threads are a Bad Idea (for most purposes).”  The discussion focuses in particular on the use of threads for GUI programming (plus web servers), which makes sense given that John Ousterhout is a systems researcher, famous for inventing TCL/TK.

The argument he gave was very simple.  Threads are too hard for most programmers to use.  Even for experts, development is painful.  Instead he advocates the use of events with handlers and event loops whenever possible.  He concludes with a warning that’s good to keep buzzing in the back of your head: “Concurrency is fundamentally hard; avoid whenever possible”

I’m inclined to say we should absolutely not be teaching freshmen parallel programming.  I’d love to hear any thoughts my non-existant audience has on the topic.  What’s that?  Oh yes, I do need to post more often if I expect anyone to read this.

Advertisements