Good Books On Programming With Threads?

uneek writes "I have been programming for several years now in a variety of languages, most recently C#, Java, and Python. I have never had to use threads for a solution in the past. Recently I have been incorporating them more in my solutions for clients. I understand the theory behind them. However I am looking for a good book on programming threads from an applied point of view. I am looking for one or more texts that provide thorough coverage and provide meaningful exercises. Anyone have any ideas?"

Comments

PThreads & Java Threads

[eldavojohn]

However I am looking for a good book on programming threads from an applied point of view. I am looking for one or more texts that provide thorough coverage and provide meaningful exercises. Anyone have any ideas?

I went through grad school not too long ago for Computer Science (disclaimer: it was the kind of computer science degree that doesn't focus on hardware so I might not be the best expert on this). Anyway there were two books for the class.

One dealt with coding regular old C on a plain jain Unix machine and method of (I believe there are others) doing multithreaded in that environment is PThreads (or the super short overview). The book we used is the Addison Wesley book (ISBN 0-201-63392-2). It was informative and comprehensive ... wasn't concentrated specifically on applications like you ask but very good reference. Also, I think there are a lot of good books free online in respect to that topic.

As for Java, there was an O'Reilly book (there's probably a new version out for Java 6) that was pretty good. Not as great of a reference but better on applications of threads in Java. Although, as far as introductory material, I personally learned it all from java.sun.com. Although I can't vouch for whether this is an applied approach or not, I would suggest the concurrency tutorial and a good book on Java Patterns or even a design pattern wiki.

I've never done concurrent programming in C# or Python so I do not know first hand what is best. I do know that erlang has been fun to mess around with in my spare time though!

Recently I have been incorporating them more in my solutions for clients.

Most important rule of thumb of multi-threaded programming is to avoid it if possible. Maybe hardware (multi-core) will change that, maybe you feel the scheduler can't do its job as well as you can and maybe you feel it's more intuitive. But, often is the case, that you're just adding more complexity to your code resulting in more difficult bugs and harder maintenance for others. Keep it simple.

Re:PThreads & Java Threads

[zolaar]

Erm, the tenets of programming usually involve the general concept of "Eliminate the unnecessary." Therefore, the parent is correct: if multi-threaded processing is unnecessary, avoid it.

What you meant to add to the dicussion is the corollary: If it is unavoidable, use it wisely.

Re:PThreads & Java Threads

[fitten]

I'm pretty sure that stuff was some rumor that came out before Barcelona was released about how the Barcelona core was going to 'destroy' Core2 (basically a load of wild and crazy speculation).

There's already some parallelisation of sequential code in all modern processors (out of order execution) that works well because it has fairly narrow focus on the instruction stream window. Going out further would be a much, much larger problem. Looking for parallelism in larger windows of the instruction stream, to the point of trying to execute whole 'subroutines' in parallel would require vast analysis (and probably not be very viable anyway as most routines are serial with respect to other subroutines.

So far, such parallelism has only been taken advantage of because the programmers put either explicit threading into the source code (pthreads and other threading APIs) or at least put hints into the code (OpenMP). This isn't a new problem... it's been around for many decades now and, so far, there haven't been really any success in automated tools to thread code. Languages like Erlang and functional languages take advantage of the fact that some language semantics allows parallelism.

Java Concurrency in Practice

[mckayc]

I highly recommend this book if you are doing threads or any sort of concurrent programming in Java. It's written by the guys who designed Java's concurrency features.

Re:Use processes whenever possible

[QuoteMstr]

No. IPC is dirt cheap. Take X11 for example -- that's perfectly usable using plain old named pipes, even without Xshm.

Most of the time, a threaded GUI program will want to use threads in order to perform some operation or another "in the background" while the UI remains responsive. If this operation has well-defined inputs and outputs, why not write it as a separate program? Communication overhead is going to be low.

The answer is obvious

[paulyt10]

Google. Finds answers much faster than reading.

Re:Use processes whenever possible

[PotatoFarmer]

Communication overhead may be low, but it's also more likely to be tied to the underlying platform. Why rely on an external provider when you get it free in the same process space?
There's also the issue of process management. When the other end of that named pipe breaks, what happens to that separate process? Is it really dead? If it's still alive, how do you kill it cleanly?
I'm not saying separate processes are bad, I'm saying that they're appropriate for certain problems, just like threaded applications are appropriate for other problems. Picking your technology and then trying to mold your solution to fit it is backward.

Re:Use threads

[goose-incarnated]

Say goodbye to IPC and all its problems, say hello to shared memory space and all its problems ;-)