4 ms·

How about teaching programmers to program without using threads? edit: sure downmod me. It's crazy talk! How could programmers do without threads and concurren

by axod 17y ago

How about teaching programmers to program without using threads? edit: sure downmod me. It's crazy talk! How could programmers do without threads and concurrency issues and all of the other blocking problems. Hardware should handle multiple cores. Not programmers.

bioweek 17y ago
Sounds like a good idea. I'd upvote you but I can't seem to vote on comments for some reason. Too young, or new?
- silentbicycle 17y ago
  It looks like your karma isn't high enough.
  - bioweek 17y ago
    How high do I need?
    - wglb 17y ago
      Used to be 200, but might have gotten upped.
      - tsuraan 17y ago
        It's around 200 for downvoting, but I think upvoting is a lot lower. Closer to 20, I think, but I've been able to upvote for a really long time.
andrew1 17y ago
I think you're being downvoted because people disagree with what you're saying. In my experience you need multiple threads when you want multiple things to happen at the same time. i.e. if I have a client/server architecture and one client instructs the server to perform a long running task then I don't want the server to appear frozen to all my other clients, which it would if the server ran in a single thread. I don't really see how you can get around this. Do you have a solution?
- randallsquared 17y ago
  I may be misunderstanding your question, but it seems as though your "server" could be written as a one-request server and then you'd just start another one to listen when a request came in. If starting a new process is too slow, use a pool. Some versions of Apache use this method. It's not a panacea, but it does provide a way you could use to avoid threaded code entirely.
  - andrew1 17y ago
    OK, but surely there are cases where it would be useful (I would argue necessary) to have a single process with multiple threads - when dealing with GUIs for example.
    - randallsquared 17y ago
      No argument that there are cases where it's useful; I was just saying it's possible to avoid.
- axod 17y ago
  >> "you need multiple threads when you want multiple things to happen at the same time" Computers don't work that way. Unless you have many CPUs, nothing happens at the same time. Rewrite your 'long running task' to do things bit by bit. By effectively doing your own timeslicing, you remove the need for any locking or concurrency issues. Once you get into the habbit of programming like this, you wouldn't believe how much easier things are. FWIW this is how Mibbit backend works - thousands of connections handled in a single thread. Javascript doesn't have threads (thankfully). There is no need for threads. They look like magic, but they cause more issues than they solve IMHO. The mapping of 'work' onto physical CPUs should be done silently by the hardware IMHO (If you have more than one CPU).
  - andrew1 17y ago
    I appreciate that nothing happens at the same time on a single core but CPU time is shared between threads so it 'appears' as if more than one thing happens at once. A good example of this is a web browser on a single core machine - the browser does not freeze up while it is downloading data. That is because the CPU time is shared between the UI thread and the other worker threads.
wglb 17y ago
There is probably more traction from what you are saying that some of the commenters suggest. For compute bound tasks, it is often productive to split computations into long-running processes. There are two reasons that the discussion goes beyond what you suggest, I think. One is detailed in http://www.tbray.org/ongoing/When/200x/2009/09/27/Concur-dot-next http://www.tbray.org/ongoing/When/200x/2009/09/27/Concur-dot... where the wide finder project is a way to explore relatively easy ways to split a log-searching task into effective threads on a multi-core machine. This is really a hard problem, as evidenced by Tim's long series of articles detailing various forays into clojure and other languages. Your comment "Hardware should handle multiple cores" reflects the opposite of what I think chip manufacturers are thinking. They run into the performance barrier, so they build a chip with more CPUs on it and hand the problem off to the compiler team and the rest of the software world. I would take it another step further in challenging hardware manufacturers to look at the broader problem. There was an article recently that noticed that for Lisp, the effective performance gain over a decade or two went up by 50 where for C-family programs it went up by several orders of magnitude. To me this implies that hardware isn't going in the direction that supports higher-level computing. Remember when the 360 instruction set came out? The 7094 people looked at it with some sense of dissapointment. And where are the nice instruction sets as evidenced by the PDP-10 and family? Perhaps this implies smarter cores so that we don't have to do so many of them. But in today's world, it seems that the languages that work well with multiple threads have a language construct that is required to make it work--libraries don't do the trick. The clean channels of GO and the constructs in Clojure point the way. Maybe the GIL-fix approach is truly doomed. So I agree with your closing sentiment.
dkersten 17y ago
And hardware can handle concurrency - you just need to switch to a dataflow language.

by axod 17y ago

bioweek 17y ago

Sounds like a good idea. I'd upvote you but I can't seem to vote on comments for some reason. Too young, or new?

silentbicycle 17y ago
It looks like your karma isn't high enough.
- bioweek 17y ago
  How high do I need?
  - wglb 17y ago
    Used to be 200, but might have gotten upped.
    - tsuraan 17y ago
      It's around 200 for downvoting, but I think upvoting is a lot lower. Closer to 20, I think, but I've been able to upvote for a really long time.

andrew1 17y ago

I think you're being downvoted because people disagree with what you're saying. In my experience you need multiple threads when you want multiple things to happen at the same time. i.e. if I have a client/server architecture and one client instructs the server to perform a long running task then I don't want the server to appear frozen to all my other clients, which it would if the server ran in a single thread. I don't really see how you can get around this. Do you have a solution?

randallsquared 17y ago
I may be misunderstanding your question, but it seems as though your "server" could be written as a one-request server and then you'd just start another one to listen when a request came in. If starting a new process is too slow, use a pool. Some versions of Apache use this method. It's not a panacea, but it does provide a way you could use to avoid threaded code entirely.
- andrew1 17y ago
  OK, but surely there are cases where it would be useful (I would argue necessary) to have a single process with multiple threads - when dealing with GUIs for example.
  - randallsquared 17y ago
    No argument that there are cases where it's useful; I was just saying it's possible to avoid.
axod 17y ago
>> "you need multiple threads when you want multiple things to happen at the same time" Computers don't work that way. Unless you have many CPUs, nothing happens at the same time. Rewrite your 'long running task' to do things bit by bit. By effectively doing your own timeslicing, you remove the need for any locking or concurrency issues. Once you get into the habbit of programming like this, you wouldn't believe how much easier things are. FWIW this is how Mibbit backend works - thousands of connections handled in a single thread. Javascript doesn't have threads (thankfully). There is no need for threads. They look like magic, but they cause more issues than they solve IMHO. The mapping of 'work' onto physical CPUs should be done silently by the hardware IMHO (If you have more than one CPU).
- andrew1 17y ago
  I appreciate that nothing happens at the same time on a single core but CPU time is shared between threads so it 'appears' as if more than one thing happens at once. A good example of this is a web browser on a single core machine - the browser does not freeze up while it is downloading data. That is because the CPU time is shared between the UI thread and the other worker threads.

wglb 17y ago

There is probably more traction from what you are saying that some of the commenters suggest. For compute bound tasks, it is often productive to split computations into long-running processes. There are two reasons that the discussion goes beyond what you suggest, I think. One is detailed in http://www.tbray.org/ongoing/When/200x/2009/09/27/Concur-dot-next http://www.tbray.org/ongoing/When/200x/2009/09/27/Concur-dot... where the wide finder project is a way to explore relatively easy ways to split a log-searching task into effective threads on a multi-core machine. This is really a hard problem, as evidenced by Tim's long series of articles detailing various forays into clojure and other languages. Your comment "Hardware should handle multiple cores" reflects the opposite of what I think chip manufacturers are thinking. They run into the performance barrier, so they build a chip with more CPUs on it and hand the problem off to the compiler team and the rest of the software world. I would take it another step further in challenging hardware manufacturers to look at the broader problem. There was an article recently that noticed that for Lisp, the effective performance gain over a decade or two went up by 50 where for C-family programs it went up by several orders of magnitude. To me this implies that hardware isn't going in the direction that supports higher-level computing. Remember when the 360 instruction set came out? The 7094 people looked at it with some sense of dissapointment. And where are the nice instruction sets as evidenced by the PDP-10 and family? Perhaps this implies smarter cores so that we don't have to do so many of them. But in today's world, it seems that the languages that work well with multiple threads have a language construct that is required to make it work--libraries don't do the trick. The clean channels of GO and the constructs in Clojure point the way. Maybe the GIL-fix approach is truly doomed. So I agree with your closing sentiment.

dkersten 17y ago

And hardware can handle concurrency - you just need to switch to a dataflow language.