I heard the claim today that multithreading in software development is obsolete, and that the whole concept of threading is based on older chip designs. I found this a little odd, since my reading indicates that multi-core processors are suited for multithreading and for scalable, high-performance applications to take full advantage of multi-core processors, you should be using multithreading.
I understand all the drawbacks associated with writing threaded applications (such as race conditions, debugging difficulties, etc.), so I’m interested in examining the above claim. Does anyone know where it comes from, or can anyone point me to online articles I can read? The person who made this claim is knowledgeable about CS, so I’m reluctant to dismiss the claim without doing my own research.
People will be writing multithreaded programs for a long time, so it’s not obsolete by any means. However, there’s a general recognition that making a programmer do their own parallelization is a good way to cause bugs, and so there’s a lot of research effort going into mechanisms for automatic parallelization. That’s mostly on the programming languages side, but there’s also some stuff going on in hardware too.
Well, if he’s talking about research into automatic parallelization, that’s one thing, but the claim made it sound like there were imminent breakthroughs around the corner which would translate to off-the-shelf compilers shortly (perhaps I read too much into the claim). And I still find his statement difficult to reconcile with the papers that come out of multi-core companies touting the benefits of multithreading on their processors.
There are languages already out there that do what I’m talking about–Erlang is probably the most famous–but there’s so much legacy code and such a high learning curve for these new languages that multithreading is not going away any time soon.
Edit: If you have a chance, ask him to clarify. I’d be curious as to what exactly he has in mind.
Hmm… he is a bit on the theoretical side, so perhaps he was referring to something like Erlang (which for us is completely theoretical, I don’t see us going that route anytime soon). I guess I’ll have to ask him. Thanks for the input.
Multi-threading isn’t based on old chip designs, but OS functionality is supported in low level hardware for newer hardware, so multi-processing environments where the OS and hardware logically isolate processes is more efficient now. At the application level, this is certainly the way to go. So obsolesence is a reasonable way describe a functional mode that has a superior alternative. But it’s not a very practical use of the term since the existing multi-threaded code is worth more today than the theoretical multi-process code not yet written.
Multi-core processors have made automatic parallelization easier to do in some cases, but also introduces a new set of problems.
Other than adding functions to support synchronization between processes, I don’t know of anything that Erlang does that wouldn’t be available in other languages with same set of functions added.
TriPolar, given the context of the discussion that was going on, that’s probably what he was getting at. It was the term “obsolete” that was throwing me.
I have heard the statement that threads are “being phased out” or are going “obsolete”. I know what is meant and don’t quibble, but it isn’t true at the concept level nor at the applied level.
The person I was talking to who said that threads were going obsolete simple meant that in .Net 4.0 Microsoft has introduced the Parallel Task Library and recommends its use in many cases as opposed to the older threading model. The TPL optimizes Managed Code For Multi-Core Machines.
When I rewrote our software from using the threadpool classes to using TPL, we saw a large reduction in processor usage. The basic structures were the same (heck, I barely changed any code) but we used tasks instead of threads.
What exactly do you mean by “reduction in processor usage”? A reduction total CPU time required to finish the complete task? Reduced load (which may or may not be a good thing)? What about wall-clock time?
Anyway, as for the OP; threads aren’t going anywhere at the basic level, simply because multi-core machines aren’t going anywhere and threading (that is, direct memory sharing), when possible, is the most efficient way of using multiple cores.
I do think that direct programmer control of low-level threads with semaphores and locks etc is going to be largely replaced by languages/toolkits that use abstractions that are easier to handle and/or automate under shared memory systems (probably by putting more emphasis on functional-style algorithms with conceptually immutable data types).
A related topic is the use of clusters, where low-level threading semantics are probably not very useful at all, since “direct” or emulated memory sharing is generally too slow over clusters, but some higher level abstractions can be made to work on both shared-memory (when available and efficient) and multi-node systems.
Anything that needs performance comes with a host of baggage that makes broad claims about the “best” way of doing it essentially meaningless. The biggest issue in most performance critical code is memory latency. Which means caches and their performance. Then comes synchronisation overhead. The elephant in the room is scalability, which is pretty much assured of breaking any model you use at some point. Threads, aka multiple concurrent threads of control in the same virtual address space are the low level brick from which almost any high performance code is built. But they are indeed hard to program, error prone, and easy to get wrong.
On the other hand, threads as a programming paradigm are also very useful. Languages that have them as intrinsic features tend to call them things like “processes” even if they do live in the same address space. A thread of control that has its own data provides a useful encapsulation of state, including execution state. If you are writing server systems, or really anything that has to handle many outstanding concurrent request streams, it is a natural way of programming.
The big difference is really that “threads as a software construct” may have many many more threads than physical CPUs, whereas threads for performance has a one to one mapping (and indeed typically a direct mapping (CPU affinity) keeping a thread on the same CPU, to maintain cache locality.) There is a huge difference between these paradigms. For threads/processes as a software abstraction the use of a managed environment, rather than down to the metal code is likely the proverbial good thing. If this means raw posix style “threads” are obsolete in this use, than the answer is probably both “yes” and “good riddance”. Experience is very often that lots of bugs go away, and performance can improve. But, if you need down to the metal hand crafted performance, threads will never go away. Even on large clusters the typical building block is a two socket high end Xeon, or AMD equivalent, with at least 8 and soon 16 plus cores. The basic algorithms that run on the nodes will be threaded. Sometimes you use a couple of threads as data marshallers and overlap communication with computation. Or the data interconnect is smart enough to do this for you. To get the performance you are getting close to real time tuning of the code. And scalability will always come to bite you.