5 ms·

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 happ

by 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.
  - axod 17y ago
    Possibly in some browsers. An alternate (better) model would be to simply have a single thread with a main loop, have async networking, and UI updates periodically in the same thread. while(true) { networking.check(); // Check if any sockets are ready for read/write/connect ui.update(); // Update the UI a bit if needed } The only case this would be a terrible idea is if you don't have control of all the code, or need to interface to things that may block/crash/etc.
    - gaius 17y ago
      This is how Tcl works.
    - coliveira 17y ago
      This only works if the UI library has good performance. During years this was a big issue in Java, and why it really needed multi-threading.
    - scott_s 17y ago
      No modern web browser controls all of the code, since it must execute arbitrary JavaScript - which can block and crash. Everyone doing something doesn't make them right. But when all major instances of an application are implemented differently than you think is best, perhaps you don't understand the problem as well as you think you do. Chrome, I think, is the best browser architecture, and it looks like IE and Firefox will adapt something similar. I think they use separate processes to manage tabs instead of threads, but it's still parallel.
j_baker 17y ago
It's not so much that I disagree with him/her. In fact, I would love it if we could do away with memory sharing. It's just that it seems a bit utopian (especially the argument that the hardware should do it for you). My understanding is that he/she wanted to have the hardware handle concurrency automatically. Unfortunately, I don't see any way to get around having software dealing with concurrency.

by andrew1 17y ago

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.
- axod 17y ago
  Possibly in some browsers. An alternate (better) model would be to simply have a single thread with a main loop, have async networking, and UI updates periodically in the same thread. while(true) { networking.check(); // Check if any sockets are ready for read/write/connect ui.update(); // Update the UI a bit if needed } The only case this would be a terrible idea is if you don't have control of all the code, or need to interface to things that may block/crash/etc.
  - gaius 17y ago
    This is how Tcl works.
  - coliveira 17y ago
    This only works if the UI library has good performance. During years this was a big issue in Java, and why it really needed multi-threading.
  - scott_s 17y ago
    No modern web browser controls all of the code, since it must execute arbitrary JavaScript - which can block and crash. Everyone doing something doesn't make them right. But when all major instances of an application are implemented differently than you think is best, perhaps you don't understand the problem as well as you think you do. Chrome, I think, is the best browser architecture, and it looks like IE and Firefox will adapt something similar. I think they use separate processes to manage tabs instead of threads, but it's still parallel.

j_baker 17y ago

It's not so much that I disagree with him/her. In fact, I would love it if we could do away with memory sharing. It's just that it seems a bit utopian (especially the argument that the hardware should do it for you). My understanding is that he/she wanted to have the hardware handle concurrency automatically. Unfortunately, I don't see any way to get around having software dealing with concurrency.