Actually, plain threads indeed are pretty much the goto's of parallel computing, one difference being that while various techniques analogous to "structured programming" - "structured threading", if you like - are available, they all work for some systems better than others, and often aren't very portable/ubiquitous yet. So right now they can't almost-kill raw threads the way ifs, fors and whiles almost killed goto's.
There was a very interesting discussion between Cliff Click and Rich Hickey (linked at bottom). The highlight of it for me was Cliff Click suggesting that people often assume that because we use a range of great abstractions every day, garbage collection was his example of a very successful abstraction, there is tendency among programmers to assume that all abstractions are great. Cliff Click gives the example of a MPI as an abstraction which proved powerful in some domains but very fragile in general.
As far as I can tell we are still looking for a really good abstraction to replace threads.
Personally I'd probably label MPI as "too low-level" an abstraction, not unlike threads; and I think there are many great high-level threading abstractions which I wouldn't call fragile, from Cilk/TBB and the like to transactional memory.
What I meant to say was, Cilk/similar can be very useful at times, transactional memory at other times, Erlang-style fully isolated lightweight processes at still other times, etc. - and none of these approaches comes with a universally available interface, also none is universally taught (while threads are.)
So my guess is that raw threads will be used increasingly less but (A) it will take time and (B) either we miss something right now or it will take more mechanisms and approaches to replace raw threads than it took to replace goto.
That said, anyone needing to do something with threads today at any sort of scale (even if it's one guy who writes something that needs to be maintained over a long span of time) should IMO hide the threads behind something. (My take on it is https://github.com/yosefk/checkedthreads)
That is a very fair statement. It is certainly true that threads are a more successful abstraction than garbage collection.
Perhaps a better statement is to observe that garbage collection has improved continuously over time and expanded the range of applications where garbage collection is used (as an aside if we look at the GC systems developed by Azul we get a indication of where GC can take us in the future).
Meanwhile the abstractions we are using to replace threads tend to be restricted to certain domains. A recent example of this would be the really interesting discussion around the use of green threads in Rust.
Rust started with a user-space light weight threads system built into the language and has since pushed that into library. The issue was that green threads are tricky abstraction in some domains.
Although my comment above was clumsy, I really just wanted to add the linked conversation between Rich Hickey and Cliff Click, because I felt it was a really good illustration of what josefk was saying, which I understood to be roughly that the comparison with GOTO isn't quite right, because we don't have a small neat set of constructs, like if, while and for etc, to replace it. Replacing threads looks like it will be much harder.
I am a bit confused, what is the relevance of that paper to the comment? Unless I misunderstood, the comment appeared to be about flow control issues of exceptions(hidden control flow and corrupt state), and I don't see that addressed in that paper.
The paper is about subroutines (function calls) being a lot less complex because all a subroutine can do is finish and then go back to its caller. There are no semantics in subroutines for jumping around willy-nilly.
I don't really agree there. Exceptions can only break out. They're a moderately stronger form of return. You can't create spaghetti control flow with exceptions.
There is a reason exceptions are often banned from environments and it isn't because they are awesome. They make code "exceptionally" (zing) hard to reason about.
They can be bad without being goto-like/unstructured. You can make a lot of the same arguments about break statements when it comes to skipping code and reaching a statement without being sure what the previous statement was or screwing up your loop.
13 comments
[ 319 ms ] story [ 132 ms ] threadThere was a very interesting discussion between Cliff Click and Rich Hickey (linked at bottom). The highlight of it for me was Cliff Click suggesting that people often assume that because we use a range of great abstractions every day, garbage collection was his example of a very successful abstraction, there is tendency among programmers to assume that all abstractions are great. Cliff Click gives the example of a MPI as an abstraction which proved powerful in some domains but very fragile in general.
As far as I can tell we are still looking for a really good abstraction to replace threads.
http://www.azulsystems.com/blog/cliff/2008-05-27-clojure-stm...
What I meant to say was, Cilk/similar can be very useful at times, transactional memory at other times, Erlang-style fully isolated lightweight processes at still other times, etc. - and none of these approaches comes with a universally available interface, also none is universally taught (while threads are.)
So my guess is that raw threads will be used increasingly less but (A) it will take time and (B) either we miss something right now or it will take more mechanisms and approaches to replace raw threads than it took to replace goto.
That said, anyone needing to do something with threads today at any sort of scale (even if it's one guy who writes something that needs to be maintained over a long span of time) should IMO hide the threads behind something. (My take on it is https://github.com/yosefk/checkedthreads)
Feels like a fun time to be programming, while we search for the right set of abstractions. :)
Isolated preemptible processes are a more successful abstraction than GC or threads. Why are threads the comparison point for concurrent abstractions?
Perhaps a better statement is to observe that garbage collection has improved continuously over time and expanded the range of applications where garbage collection is used (as an aside if we look at the GC systems developed by Azul we get a indication of where GC can take us in the future).
Meanwhile the abstractions we are using to replace threads tend to be restricted to certain domains. A recent example of this would be the really interesting discussion around the use of green threads in Rust.
https://mail.mozilla.org/pipermail/rust-dev/2013-November/00...
Rust started with a user-space light weight threads system built into the language and has since pushed that into library. The issue was that green threads are tricky abstraction in some domains.
Although my comment above was clumsy, I really just wanted to add the linked conversation between Rich Hickey and Cliff Click, because I felt it was a really good illustration of what josefk was saying, which I understood to be roughly that the comparison with GOTO isn't quite right, because we don't have a small neat set of constructs, like if, while and for etc, to replace it. Replacing threads looks like it will be much harder.
There is a reason exceptions are often banned from environments and it isn't because they are awesome. They make code "exceptionally" (zing) hard to reason about.