Parallelism
Threading in current programming models is one of the hardest things to get right. It appears to be a fabulous tool waiting to be exploited, but it is instead one of the hardest things to get right. Mike Stall has an interesting take on the combinatorial nature of multithreading and how the possible areas for bugs balloon as the number of threads increase. Similarly Jeff Atwood goes into details about it as well.
Some people say that the solution is in the languages. Fix the languages and then you've fixed the threading problem. I don't know if I believe in that silver bullet. You get some benefit in purely functional languages. When I was in college nearly 20 years ago (eep!), I took a seminar course about functional programming. In the class, we were presented with the graph reduction approach to program evaluation. Essentially, the approach is to represent the code as a graph which can be reduced to a single node. Part of the approach is one that allows for multiple processors/threads to work on the same graph at the same time with a minimum of critical sections. Simon Peyton Jones visited campus as a guest lecturer and honors examiner and talked about this as well. Jones has his hands in a number of interesting technologies, including Haskell.
In DotImage, we added threading into our image processing. To do this, I created a meta-command called ThreadedCommand. This command acts like an ImageCommand but does no image processing. Instead it breaks an image into bands, and throws worker threads at the bands.
Rather than deal with full concurrency, we limited the domain of the problem instead. Not every ImageCommand can be effectively threaded. Instead, we use the following rules. An ImageCommand can be threaded if:
- It implements IConeable. We do not use the same command on every thread. Instead, we use clones so as to avoid internal state issues within the command.
- It does not modify the source image outside a given scanline and if it does modify within a given scanline, it requires no state outside of a given scanline.
- It requires no state calculated from one band for use in another
- It implements IThreadableCommand (our interface)
By abiding by these rules, it is possible to thread many ImageCommands without a deep knowledge of threading, which is the way I think it should be.
Now, in implementing this we built a worker thread library and it was far more painful than it should've been. We looked for support code that we could use in our environment (we had to support .NET 1.1 and above) and found nothing usable, which is a crime because our needs are simple: this code needs a set of workers, a queue of jobs, a way to start workers running, a way for them to report completion, and a way to kill them instantly. Every single one of these things was hard to do right, even when we stacked the deck in our favor. That tells me that the underlying threading tools need other support classes on top of them - badly.