Hi Peter,
On 4/14/05, Peter Wilson
> Do you know of any books on threading in software design written at
> the level of Design Patterns?
Sounds like a great book. I want a copy! 8-)
There have been some interesting articles recently in C++ journal, but I haven't seen any of the "newer thinking on threads" gathered into a book.
This is going to become more critical RSN as the multi-core chips hit the market. Maybe I should write a book!
Rule #1: Multithreading code is hard.
Corollary: If you don't think it's hard, your code is wrong! (witness Java synchronized)
Rule #2: If the hardware isn't involved at some point, it's wrong.
There are no software-only synchronization methods. This doesn't mean you have to lock a mutex every time you touch shared data. It just means that somewhere in any thread safe technique there has to be a mutex (or the moral equivalent.)
Rule #3: Don't try to cheat -- particularly not for performance sake.
Multithreading buys you performance through parallelism, not
through shoddy coding techniques. (remember the Double Checked
Locking Pattern? (and see my blog for TCLP))
Rule #4: You need a model.
If you wing it, or play it by ear, you'll get it wrong (I'll put money on it.) Separate the thread-safeness from everything else and get it right in isolation. Then use encapsulation to keep "the next guy" from cheating.
Rule #5: Testing multithreading code is harder (and more important) than writing it in the first place.
how'm I doing?
Dale
2 comments:
Rule #2 is wrong. There's a software only solution to building a Mutex, called Dekker's algorithm, which is the building block for thread safe code.
http://www.cs.wvu.edu/~jdm/classes/cs356/notes/mutex/index.html
Dekker's algorithm (and Peterson's algorithm) work on a single processor system, but fail on a multiprocessor system where each processor has its own cache.
That includes almost all multiprocessor systems in existence today. I don't know how cache will be handled on multi-core chips -- it could be interesting.
Maybe the "shared" modifier in the pseudo-code examples you cite means that cache is somehow bypassed or disabled in accessing this memory, but in that case, Rule #2 applies -- you have hardware assisted synchronization. I didn't say it had to be a mutex, I said it had to be "the moral equivalent" of a mutex so the question has been reduced to "how do you implement shared.
Post a Comment