Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: I haven't found a decent book, but... (Score 2, Informative) 176

by EWIPlayer (#25289573) Attached to: Good Books On Programming With Threads?

Herb Sutter has been doing a lot of work on this stuff over the last 10 years and his blog is full of stuff on what you should do... it's not too nitty gritty in terms of languages and stuff, but it's very informative in terms of understanding the issues and what not. Check out

Some rules of thumb that I've found useful:

  • Hide mutexes and locks at (nearly) all costs. If you have a queue class, for example, that has a locking push() function, and someone needs to lock for a series of pushes, don't expose the lock to let them lock things for the series of pushes, but provide a push function that takes a list of items instead. Keep thinking of ways to hide your locking strategies. If your class is deadlock-free then you can be reasonably sure (I've always said "reasonably" but I've never seen it not work either) that you'll never see a deadlock in real life either. Race conditions are a different story, however.
  • Trying to figure out a solution where you never have to think about the concurrency of things is a scary place to go... Have a logical concurrent model instead. For example, if you work with user's and user's get events, rather than just letting them process any number of events in parallel, it may be reasonable to sequence events per-user and let the users run in parallel.
  • If you do have to expose locks, use a locking hierarchy. Herb shows this here:
  • Avoid any concept of being impolite among your threads (i.e. forced interrupts or kills). Be polite. Herb has this here:
  • Locking sucks, but it's necessary. If you think you can get away without having to lock in a dubious situation, you're probably wrong.
  • Unit test, unit test, unit test. If your classes hide all of your locks, then unit tests cover a ton of cases.

I believe that following strict OO guidelines is even more important when dealing with concurrency than when dealing with general ideas in software... and let's face it, it's extremely important even when not dealing with concurrency :)

Have you ever noticed that the people who are always trying to tell you `there's a time for work and a time for play' never find the time for play?