One of the most talked about features in the new Flash Player 11.4 beta is the new concurrency model which allows developers to spawn worker threads to handle intensive operations. While many people are singing the praises of multithreading, I can't help but to feel like this may not be such a great thing.
I've always had certain misgivings about multithreading. Without question, threading has become common practice for achieving performance gains through parallelism in programming. However, just because something becomes accepted practice does not necessarily mean that it's a good thing. If you want an exhaustive look into the topic, I recommend reading Edward A. Lee's report The Problem with Threads. The author is a distinguished professor and former chair of Berkeley's Electrical Engineering and Computer Sciences department.
While Professor Lee's report goes into great detail about the problems surrounding threading, I will present my misgivings at face value. Threads violate three programming principles that I view as vital to successful application development:
1) Threads create complexity rather than alleviate it
2) Threads increase potential points of failure
3) Threads are nondeterministic
1) Threads create complexity
If you read my post on how to be a better programmer, then you know that one of the tips there was to keep things simple whenever possible. Threads violate this in spectacular fashion. While many languages have adopted API's that make working with threads more manageable, they are still more difficult to follow for a developer maintaining a program. This becomes especially true in cases where the developer is not the original author of the code. If the threaded code is poorly commented (or not at all) then it can become an arduous endeavor to figure out what it is supposed to be doing. This is true enough for sequential programs, but the problem is compounded when you have strands of code going off in different directions and converging at some later point in time. Threading is perhaps the ultimate realization of the term "spaghetti code."
Unfortunately, unlike other languages such as C#, the threading API introduced in ActionScript isn't exactly intuitive. It's a fairly convoluted process at the moment which includes creating a separate swf for each worker thread, message channels and event listeners.
2) Threads increase points of failure
A pessimist once said "anything that can go wrong will go wrong." Perhaps that person was a programmer because in software development if there's a bug in the code it will, at some point, make itself known. Debugging software is already a mostly hopeless task. All but the most trivial of programs contain bugs (Flash is a fine example) and threading introduces fun new ways for programs to ruin a user's day. These aren't small bugs either; issues such as deadlocking and synchronization problems are catastrophic failures.
In his report, Professor Lee demonstrates how even a simple, often-used design pattern quickly spirals out of control when multithreading is introduced. With regards to concurrency bugs he states:
"I speculate further that the bugs have not proved to be major handicaps only because today’s architectures and operating systems deliver modest parallelism. The cost of context switching is high, so only a tiny percentage of the possible interleavings of thread instructions ever occur in practice. I conjecture that most multi-threaded general-purpose applications are, in fact, so full of concurrency bugs that as multi-core architectures become commonplace, these bugs will begin to show up as system failures."
3) Threads are nondeterministic
Lastly, threads are nondeterministic. They are not as predictable as a sequential program. You can do your best to make them deterministic, and many languages have implemented features to help with this, but as Professor Lee points out: "Threads, as a model of computation, are wildly nondeterministic, and the job of the programmer becomes one of pruning that nondeterminism." Given all the variables in thread timings and scheduling by a given OS, knowing the state of a multithreaded application at any given time becomes a guessing game and reproducing serious bugs can be an impossible task.
While I've never been a big proponent of multithreading, I also concede that I'm not an authority on the subject. Professor Lee's report was published in 2006 and I thought that perhaps by now threading techniques had sufficiently advanced to make them safer. It's been a couple of years at least since I last wrote a multithreaded program and I thought perhaps I was just out of the loop. Prior to writing this piece I contacted Professor Lee asking if his report was still relevant today. He was gracious enough to respond quickly and confirmed that his claims about the problems with multithreading still stand.
Am I saying you should never use threads? No, but I would caution you to carefully evaluate the benefit of doing so and to take into consideration the negative consequences of threading. It seems to me that developers are far too gung-ho on threading and use it irresponsibly simply because they can.
If you would like to experiment with the AS3 concurrency API, Lee Brimelow has posted a two part tutorial on his gotoandlearn site. You can also download the Flash Player 11.4 and AIR 3.4 betas. As mentioned earlier, the API is rather clunky at the moment. Hopefully this implementation will be cleaned up in the next version of ActionScript.