So How Are We Doin', One Programmer Asks Another

"So how are we doing?" James Reinders rhetorically asked a roomful of programmers at SD West 2009 when referring to his Eight Rules for Parallel Programming for Multicore.

1. Think parallel
   
2. Program using abstraction.
   
3. Program in tasks, not threads
   
4. Design with the option to turn concurrency off
   
5. Avoid using locks
   
6. Use tools and libraries designed to help with concurrency
   
7. Use scalable memory allocators
   
8. Design to scale through increased workloads.
   

And the answer? Pretty good in the center, said Reinders, althought there's work to be done on the edges. The "center", the "edges"? What Reinders was referring to were rules #1 and #8 -- "Think parallel" and "Design to scale", respectively. Thanks in large part to emerging tools like those included in the Intel Parallel Studio toolkit (now in beta), the rules in the middle -- #2 through #7 -- seem to be in hand, to some extent. However, developers still need to starting thinking parallel and designing accordingly.

"It's very important to make sure, if at all possible, your program can run in a single thread with concurrency off," said Reinders. "You shouldn't design your program so it has to have parallelism. It makes it much more difficult to debug."

That said, locks remain a big issue, leading Reinders to revise rule #5 -- "avoid locks". Thanks in part to input from the likes of Herb Sutter, Reinders now thinks that a few locks are okay, and probably better than no locks at all since Parallel Studio tools make it easier to find bottlenecks and identify problematic locks. Reinders followed up on the topic of locks in a standing-room-only BoF gathering later that evening.