Writing Multithreaded Programs Can't Be Done In C - Spolsky
Sunday, 11. October 2009, 23:24:45
Found this via reddit.
I'll quote it here for those that don't want to go to the link.
Emphasis mine. Those sections in bold leave me scratching my head. Spolsky is known for saying outrageous things, but I never thought he was on par with Richard Stallman and Linus Torvalds.
Is it hard to get multithreaded programming right? Sure. But Spolsky is saying that it's humanly impossible. That "it's just not gonna work, it's just not gonna make you happy. So there." Give up now.
Personally, I'm not a big fan of threads. I find too many people use them when there's no need. But those needs do arise from time to time. Blocking calls are the biggest problem. Other times, it just makes sense to separate code into their respective units that have their own execution point. For example, I once wrote a backgammon server and separated the database part from the rest of the server. I eventually put it in its own process so that it could be run on a different machine, but the principle is the same. The server and database handling run in parallel (or concurrently if you want the proper term). Why would database access need its own thread? Because when you make a request, you need to wait for the actual database program to return you a result. During that time, delays can be caused by different things like network latency if on a different machine, disk latency, processing (if using multicore), etc. So during that time, you have free processing power that is going to waste. By having another thread(s) for the main server, you can process other requests while waiting for the database to return a response.
Are there other times you need to use threads? Well, this is probably what Spolsky actually meant (though I can't be sure). That when we go to multicore, Spolsky would prefer to use functionality that is simpler to use for using all the cores such as special "parallel" commands found in many languages. These will send statements to different processors to be computed and then the "parallel" command will put the results back together in the correct order. A simple (and not very good example) might be to increment numbers in a list. No locking needed and each processor can increment their respective ranges within the list.
Are there ways to simplify your life when programming multithreaded programs in C or C++? Yeah. I've talked about this many times. Over and over again, I've promoted the idea of having systems or global modules that only talk to other modules through data messages (without a function call). In effect, each module essentially acts like a separate process. But you have the advantage that you have shared memory and message passing can happen so much easier and simpler. So if you ever need to extract the module into it's own process, it's no big deal. Also, any globally shared data would simply be put into a module of its own. And then I've often talked about helper classes in C++ to help insert and extract data from those messages. But that's another topic.
The biggest problem is taking something that isn't multithreaded and then trying to turn it that way after that fact. That'll cause a lot of problems because the foundation isn't built for it. Hence my promotion of self executing modules because you can expand and add more at any time.
So why would someone say multithreading is impossible? I don't know. But it made me laugh. A lot! At first, I thought he was just saying it was hard. But no. He's saying flat out impossible. Strange stuff.
edit: I wonder what Spolsky thinks of P2P software like uTorrent (written in C++). Or browsers and servers (Apache for example uses many processes and was written in C), Operating Systems, or anything distributed. Anyways, I just don't get what he was going for.
I'll quote it here for those that don't want to go to the link.
Spolsky: Quite probably. I mean C is a car, it’s very dangerous – it doesn’t have seatbelts, but it’s very powerful because it goes very fast. In fact, I’d go so far as to say, unless some people are gonna punch me about this one, but you cannot write multi-threaded code in the C programming language. You just can’t. Although technically all the capabilities are there, it is beyond the capability of mortal humans – and I know, some of you out there are very smart and you think that you have the capability of writing multi-threaded code in the C programming language, because you’re hot shit. Well, let me tell you, it is beyond the capability of humans on this planet, for their brains are just not adequate to the task of writing multi-threaded code in most languages, least of all low-level languages like C. It’s just not gonna work, it’s just not gonna make you happy. So there.
Emphasis mine. Those sections in bold leave me scratching my head. Spolsky is known for saying outrageous things, but I never thought he was on par with Richard Stallman and Linus Torvalds.
Is it hard to get multithreaded programming right? Sure. But Spolsky is saying that it's humanly impossible. That "it's just not gonna work, it's just not gonna make you happy. So there." Give up now.
Personally, I'm not a big fan of threads. I find too many people use them when there's no need. But those needs do arise from time to time. Blocking calls are the biggest problem. Other times, it just makes sense to separate code into their respective units that have their own execution point. For example, I once wrote a backgammon server and separated the database part from the rest of the server. I eventually put it in its own process so that it could be run on a different machine, but the principle is the same. The server and database handling run in parallel (or concurrently if you want the proper term). Why would database access need its own thread? Because when you make a request, you need to wait for the actual database program to return you a result. During that time, delays can be caused by different things like network latency if on a different machine, disk latency, processing (if using multicore), etc. So during that time, you have free processing power that is going to waste. By having another thread(s) for the main server, you can process other requests while waiting for the database to return a response.
Are there other times you need to use threads? Well, this is probably what Spolsky actually meant (though I can't be sure). That when we go to multicore, Spolsky would prefer to use functionality that is simpler to use for using all the cores such as special "parallel" commands found in many languages. These will send statements to different processors to be computed and then the "parallel" command will put the results back together in the correct order. A simple (and not very good example) might be to increment numbers in a list. No locking needed and each processor can increment their respective ranges within the list.
Are there ways to simplify your life when programming multithreaded programs in C or C++? Yeah. I've talked about this many times. Over and over again, I've promoted the idea of having systems or global modules that only talk to other modules through data messages (without a function call). In effect, each module essentially acts like a separate process. But you have the advantage that you have shared memory and message passing can happen so much easier and simpler. So if you ever need to extract the module into it's own process, it's no big deal. Also, any globally shared data would simply be put into a module of its own. And then I've often talked about helper classes in C++ to help insert and extract data from those messages. But that's another topic.
The biggest problem is taking something that isn't multithreaded and then trying to turn it that way after that fact. That'll cause a lot of problems because the foundation isn't built for it. Hence my promotion of self executing modules because you can expand and add more at any time.
So why would someone say multithreading is impossible? I don't know. But it made me laugh. A lot! At first, I thought he was just saying it was hard. But no. He's saying flat out impossible. Strange stuff.
edit: I wonder what Spolsky thinks of P2P software like uTorrent (written in C++). Or browsers and servers (Apache for example uses many processes and was written in C), Operating Systems, or anything distributed. Anyways, I just don't get what he was going for.
WIDGETIZE
Anonymous # 12. October 2009, 11:43
C++ is not C.
Anonymous # 12. October 2009, 13:07
I agree, in fact that's probably what he was "suggesting" over C
Anonymous # 12. October 2009, 13:41
It can be done, but not if you use pthreads, you need to use a decent library that provides sane concurrency abstractions, like libtask or libthread: http://man.cat-v.org/p9p/3/thread
vladas # 12. October 2009, 18:32
I think we should read it as "C isn't designed for routine multithreaded programming, as well as for use by mere mortals programmers. However some extremals, like Linus Torvalds and such morons like me and you are allowed to do that..."
Vorlath # 13. October 2009, 14:33
Pointers! So archaic. They STILL have registers. hehehe It's a miracle these machines run at all.
I also reread the section about the quote in the article. It's not about C++ vs. C. They're talking about things that exist in both C++ and C. They specifically attack both C and C++ immediately afterwards. They're talking mostly about the preprocessor and how you can redefine anything piece of text (as vladas correctly pointed out). But their example is stupid. I think Spolsky was trying to be funny, but meant everything he said.
Anonymous # 13. October 2009, 18:10
Message passing does not necessarily eliminate race conditions. Logic involving multiple threads working on shared data(even though the data is shared using message passing) needs to be carefully thought out. I don't think language is the problem here. Such problems are inherently more complex.