"Writing Multithreaded Programs Can't Be Done In C" - Spolsky(my.opera.com)
my.opera.com
"Writing Multithreaded Programs Can't Be Done In C" - Spolsky
http://my.opera.com/Vorlath/blog/2009/10/11/writing-multithreaded-programs-cant-be-done-in-c-spolsky
29 comments
+1
In particular, I think Joel does have a point here. Yeah, so maybe he's exaggerating by saying it's impossible. But I would imagine that multi-threading in C (like most things in C) is really difficult. Especially compared to more modern languages that make it much easier.
In particular, I think Joel does have a point here. Yeah, so maybe he's exaggerating by saying it's impossible. But I would imagine that multi-threading in C (like most things in C) is really difficult. Especially compared to more modern languages that make it much easier.
Bollocks. I made good money selling my anti-spam library polymail that is written entirely in C, tiny, fast and multi-threaded.
Your work, however, suggests that you are not actually human. Seeing some of the things you have produced makes me think that you are inhumanly competent, and hence Joel's remarks do not apply to you.
I think Joel is using a limited form of the word "impossible" and a limited form of the word "human", in a similar way that 2+2=5 for sufficiently large values of 2 and sufficiently small values of 5.
I think Joel is using a limited form of the word "impossible" and a limited form of the word "human", in a similar way that 2+2=5 for sufficiently large values of 2 and sufficiently small values of 5.
My response to this post: http://news.ycombinator.com/item?id=878919
I am very surprised that your comment got upvoted. I have done little of significance (except, perhaps, the Alan Turing petition thing).
While, unlike many here, I like Joel's posts, I do think he was exaggerating, slightly. The underlying point is that to do multithreaded in C is indeed difficult, and it is stated elsewhere that there are only a very small number of people who can make this work.
You are clearly one of them.
You are clearly one of them.
[deleted](1)
I think Joel's point is that for the following two statements:
1) You can do multithreaded programs in C
2) You cannot do multithreaded programs in C
the common belief is 1, and it leads to much suffering. If everyone believed what Joel is saying, 2, most everyone would be much happier.
He's trying to reset the center point of the thread folklore. And I praise him. Doing concurrent systems in C should sound as absurd as building web apps in assembly - there's probably a case for it, but its almost certainly not the one you're looking at.
1) You can do multithreaded programs in C
2) You cannot do multithreaded programs in C
the common belief is 1, and it leads to much suffering. If everyone believed what Joel is saying, 2, most everyone would be much happier.
He's trying to reset the center point of the thread folklore. And I praise him. Doing concurrent systems in C should sound as absurd as building web apps in assembly - there's probably a case for it, but its almost certainly not the one you're looking at.
In C, parallelize with OpenMP, do large scale concurrent work in processes and small scale concurrent work in event loops.
With the traditional lock based (pessimistic) approach, writing reliable and efficient multithreaded programs is impossible given a number "n" of threads.
This number "n" varies with the talent and experience of the programmer as well, with a less significant factor, with the language used.
That's why people are working on transactional memory. When our customers will have 100 cores in their machines, it's not realistic to hope to achieve anything with locks.
This number "n" varies with the talent and experience of the programmer as well, with a less significant factor, with the language used.
That's why people are working on transactional memory. When our customers will have 100 cores in their machines, it's not realistic to hope to achieve anything with locks.
It's just Joel doing the "Joel 'Thang"--namely effective, but disingenuous, attention marketing. Examine the context of his original statement.
Hmm...maybe his definition of multithreaded doesn't match that commonly used in the emebdded world. Lots of embedded projects are written in C, many using an RTOS to allow multiple tasks/threads to run concurrently on a single CPU.
Or for Joel, all the world's a PC.
Or for Joel, all the world's a PC.
Big surprise: blanket statements are often inaccurate!
[deleted]
It can be done, if you use the right paradigm and the right library: http://man.cat-v.org/plan_9/2/thread
If you use pthreads, then you are certainly doomed.
If you use pthreads, then you are certainly doomed.
If you use pthreads, then you are certainly doomed.
Our project has done it just fine for about 4 years. This is complete FUD.
Certainly there are use-cases where pthreads are more challenging, but for the vast majority of cases they seem to do the job just fine.
In most cases you cannot eliminate the complexity of threading. To use terms from The Mythical Man Month, it is "inherent complexity"; no matter what language or library you use, one has to find a smart way to subdivide the problem efficiently. There are implementation details that can be made simpler (reducing accidental complexity), but the problem of parallelism--the inherent complexity--will always exist.
Anyone who claims a magical way to do this without human input is lying, or at a minimum talking about situations far too simple to fit any real use-case.
Our project has done it just fine for about 4 years. This is complete FUD.
Certainly there are use-cases where pthreads are more challenging, but for the vast majority of cases they seem to do the job just fine.
In most cases you cannot eliminate the complexity of threading. To use terms from The Mythical Man Month, it is "inherent complexity"; no matter what language or library you use, one has to find a smart way to subdivide the problem efficiently. There are implementation details that can be made simpler (reducing accidental complexity), but the problem of parallelism--the inherent complexity--will always exist.
Anyone who claims a magical way to do this without human input is lying, or at a minimum talking about situations far too simple to fit any real use-case.
Some languages are structured so that the hardest parts of concurrent programming are solved for you by language features. C is not one of those languages. That is Joel's point.
The language is irrelevant, the model is what really matters, of course Limbo or any other language built around CSP will be better than libthread, but one can do CSP on pretty much any language.
One can use pthreads (or the like) in almost any language too, and it sucks infinitely everywhere.
One can use pthreads (or the like) in almost any language too, and it sucks infinitely everywhere.
>>Anyone who claims a magical way to do this without human input is lying, or at a minimum talking about situations far too simple to fit any real use-case.
I think that is correct, but hope it's wrong. (As you probably do, too.)
Anyway, thank you for making such a strong statement, so it will surely be well tested. :-)
I think that is correct, but hope it's wrong. (As you probably do, too.)
Anyway, thank you for making such a strong statement, so it will surely be well tested. :-)
Joel has his opinions about a lot of programming matters (TDD for example) and combined with his witty way of presenting stuff those opinions should not be given any seriousness than it deserves.
I personally like Joel as a writer and I do listen to his StackOverflow podcasts and I think he is being misunderstood as having strong feelings against multi-threaded programming or TDD while the fact is that he adds these superlatives for an added effect in his talks and writing. Just ignore those and you will be fine.