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.
>>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. :-)
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.
n.b. : I hit reply on the wrong post and only noticed after hitting submit
While not doomed, if you have the poor primitives you will have a bad time.
All the talk if it being so hard is because people try and figure it out for themselves while ignoring the literature. Hoare paved the way it in 1978 and basically solved the problem. I bet most programmers have barely heard of him, let alone read his work. It took 8 years to get the book printed but now it's a free download http://www.usingcsp.com/
I disagree. If you look at my comments on this site you will notice that I rarely use profanity. In this case, the claim the C was unsuitable for multi-threading coming, as it did, from someone as well known as Joel Spolsky merited a strong response.
I could have responded: "I strongly disagree with the statement in the title of this Hacker News post. It is simply nonsensical". I decided to use the word 'bollocks' as a short-cut to that meaning. To quote Wikipedia, 'The word is often used figuratively in British English, as a noun to mean "nonsense",'
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.
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.
We may want to move discussions about the daily rantings of Joel Spolsky out of Hacker News.
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.
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.
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.
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.
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.
29 comments
[ 3.1 ms ] story [ 32.1 ms ] threadIf 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.
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. :-)
One can use pthreads (or the like) in almost any language too, and it sucks infinitely everywhere.
While not doomed, if you have the poor primitives you will have a bad time.
All the talk if it being so hard is because people try and figure it out for themselves while ignoring the literature. Hoare paved the way it in 1978 and basically solved the problem. I bet most programmers have barely heard of him, let alone read his work. It took 8 years to get the book printed but now it's a free download http://www.usingcsp.com/
http://en.wikipedia.org/wiki/Transputer
http://en.wikipedia.org/wiki/Communicating_sequential_proces...
It makes me so mad :>
I could have responded: "I strongly disagree with the statement in the title of this Hacker News post. It is simply nonsensical". I decided to use the word 'bollocks' as a short-cut to that meaning. To quote Wikipedia, 'The word is often used figuratively in British English, as a noun to mean "nonsense",'
I carefully decided to use that word.
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.
You are clearly one of them.
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.
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.
http://plan9.bell-labs.com/magic/man2html/2/thread
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.
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.
Or for Joel, all the world's a PC.