4 ms·

It can be done, if you use the right paradigm and the right library: http://man.cat-v.org/plan_9/2/thread http://man.cat-v.org/plan_9/2/thread If you use pthre

by uriel 17y ago

It can be done, if you use the right paradigm and the right library: http://man.cat-v.org/plan_9/2/thread http://man.cat-v.org/plan_9/2/thread If you use pthreads, then you are certainly doomed.

DarkShikari 17y ago
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.
- berntb 17y ago
  >>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. :-)
- rjurney 17y ago
  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.
  - uriel 17y ago
    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.
- skwiddor 17y ago
  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/ http://www.usingcsp.com/ http://en.wikipedia.org/wiki/Transputer http://en.wikipedia.org/wiki/Transputer http://en.wikipedia.org/wiki/Communicating_sequential_processes http://en.wikipedia.org/wiki/Communicating_sequential_proces... It makes me so mad :>

by uriel 17y ago

It can be done, if you use the right paradigm and the right library: http://man.cat-v.org/plan_9/2/thread http://man.cat-v.org/plan_9/2/thread If you use pthreads, then you are certainly doomed.

DarkShikari 17y ago

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.

berntb 17y ago
>>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. :-)
rjurney 17y ago
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.
- uriel 17y ago
  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.
skwiddor 17y ago
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/ http://www.usingcsp.com/ http://en.wikipedia.org/wiki/Transputer http://en.wikipedia.org/wiki/Transputer http://en.wikipedia.org/wiki/Communicating_sequential_processes http://en.wikipedia.org/wiki/Communicating_sequential_proces... It makes me so mad :>