Slashdot Mirror

← Back to Stories (view on slashdot.org)

Good Books On Programming With Threads?

Posted by timothy on from the alternative-is-to-program-naked dept.

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?"

6 of 176 comments (clear)

  1. Obligatory serious needle reply by davidwr · · Score: 2, Interesting

    The Jacquard Loom involves programming of a sort, albeit without branching or computations. In that sense it's more like a translator, translating punches into patterns. Sort of like printf for the clothing industry.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
  2. Two books by grindcorefan · · Score: 2, Interesting

    First: Programming Erlang: Software for a Concurrent World
    by Joe Armstrong
    http://www.pragprog.com/titles/jaerlang/programming-erlang

    The Erlang programming language is well suited to develop concurrent programs with.

    The second book I'd recommend is
    Distributed Systems: Principles and Paradigms, 2/E
    by Andrew S. Tanenbaum
    http://www.pearsonhighered.com/educator/academic/product/0,,0132392275,00%2Ben-USS_01DBC.html

    Not specific to any programming language, but a very good introduction to the concepts and methods used developing distributed systems, as all multi-threaded programs are.

  3. What the hell? by QuoteMstr · · Score: 2, Interesting

    You don't need a book about threaded programming in Python.

    You need two books: one about Python, one about threads. Concepts are universal and can be applied across as many languages as you want. It's like saying you need to re-take Calculus because you just learned French!

  4. the little book by scoopr · · Score: 2, Interesting

    I found Little Book of Semaphores a good read.

  5. Avoiding threads..... by refactored · · Score: 3, Interesting
    1. You can avoid threads all you like... but several libraries / toolkits automagically spin threads for you. eg. If you using java graphical stuff odds on it has it's own thread whirring away doing stuff.
    2. Threads have subtle and noxious interactions with processes. Say "man pthread_atfork" sometime to see what I mean.
    3. ISRs/Timer/alarm/signal callbacks are effectively another thread context. ie. Most largish systems that claim to be "single threaded" aren't.
  6. Re:PThreads & Java Threads by ShakaUVM · · Score: 3, Interesting

    My Master's Degree was in High Performance Computing from UC San Diego, and I taught parallel processing.

    Yes, you're right that most new programmers out of college will screw up (and screw up badly) if they try to write a multithreaded application. Learning to write parallel applications requires more mind-bending mental gymnastics than, say, when you first learned to write recursive applications. That said, once you get a solid understanding of how safe parallel code should look like, and how it should work, it's fairly trivial to write code that works, and doesn't deadlock. From my experience, it takes about 3 to 6 months of pounding on parallel code to reach that state.

    While it's not a trivial amount of time, given the importance parallel code has (and will increasingly have in the future), I don't think it's too great a hurdle to ask for people to learn this stuff. All talk about multi-core programming always boils down to "Well, we'll never find enough programmers who are able to write multi-threaded apps." Well... why?

    I think it would be in the best interests of Intel and AMD to sponsor online college classes teaching how to do parallel coding. People aren't buying the new chips since code can't take advantage of it -- if they flip it around and make every program able to multithread (that could benefit from multithreading, as you point out, Amdahl's Law) then demand for their chips would surge, and they'd make the money back in billions.