2

My knowledge of threads is very limited. I happen to be the guy who can write multi-threaded programs but just by copy-pasting and finding answers to my questions on the internet. But I've finally decided to learn a bit about concurrency and bought the book "Java Concurrency in Practice". After reading a couple of pages, I'm confident that I'll learn a great deal from this book.

Maybe I'm being a little impatient but I cannot resist the temptation of asking this question. It made me create an account on Stack Overflow. I'm not sure I'll be able to correctly phrase the question so I'll try to explain my question using an example.

If I had to write a (extremely unprofessionally coded) peer-to-peer chat client in, say, Java, I'll initiate a socket connection between the clients and keep it alive because messages can arrive at any time. The solution I can imagine would open a socket connection in a new thread and run a while loop continuously to keep the thread alive, as the thread dies as soon as run returns. For some reason, I cannot imagine a similar chat client in a single threaded program. How can you keep "waiting" until a message arrives if all you have is a single thread. Won't that block the execution of entire program?

To solve such a problem, what's the alternative to a continuous while loop?

Viplav Kumar
  • 85
  • 5
  • If your chat application works in such a way that one side is always a sender and the other is always the receiver, then to a certain extent, it is possible to use a single thread to achieve this. Otherwise, you would always have a dedicated thread to do the connection stuff (or the API would have done that for you). – Jai Feb 21 '19 at 09:12
  • In short: yes. A call to `read` on a `Socket`'s inputstream blocks. That's why this is usually done with a dedicated thread. You might use `available()` to check if data is present in order not to call `read` all the time, but usually you would want a thread or a library like Mina to deal with this. – f1sh Feb 21 '19 at 09:14
  • there is such a thing like asynchronous networking. No thread needs to wait the end of I/O operation. Instead, a task (of type` Runnable`) is prepared for execution as soon as the operation finishes. It handles the event, and can start another I/O operations. – Alexei Kaigorodov Feb 21 '19 at 10:45
  • Although I understand the question, writing threads to handle your chat-client might be a ton easier than doing it single threaded. Keep on looking around for a good thread tutorial which makes sense to you. You don't need anything really fancy so basic tutorials should help. Good luck! – Gray Feb 21 '19 at 14:42
  • I don't really have to write a chat-client at the moment. I had this question in mind ever since threads were introduced to me. I'm reading the book Java Concurrency in Practice and so far everything seems straight forward. I appreciate your advice anyway. Thank you everyone for taking the time to post your valuable comments and answer. – Viplav Kumar Feb 21 '19 at 17:13
  • Found something very interesting & helpful here: https://stackoverflow.com/questions/14795145/how-the-single-threaded-non-blocking-io-model-works-in-node-js – Viplav Kumar Feb 21 '19 at 17:45

1 Answers1

1

How can you keep "waiting" until a message arrives if all you have is a single thread.

One possibility is to have the "parallelism" to happen "outside" of your application. Imagine a waiter in a restaurant. Just one guy. He walks from one customer to the next, and writes up the orders. From time to time, he walks over to the counter, puts in the orders, and picks up whatever stuff the chef left for him. Just one guy, walking around, doing "single task" work. But in the end, the overall system still has multiple actors (the guests, the waiter, the chef, the guy beyond the bar preparing the beverages). So, the waiter could be seen as "single threaded", but in the end, the overall system "restaurant" isn't.

Some IT architectures "mimic" that, for example around the idea of "non blocking" IO. That is how node.js works. It is single threaded by nature, but does async IO (see here for details). And you can do similar things with Java, too.

On the other hand, when you learn about concurrency, you still want to learn about the "real" multi threading, what it means, and how you would write code to "use" that concept.

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • Pardon my ignorance but I was unable to fit the waiter analogy in the single threaded chat application problem. What waiter does (adding to the list of orders) can be understood as the event loop in Node's architecture (No?). When the waiter goes to take an order, the cook doesn't have to wait for him to return to prepare food. He can simply take one out from the queue of orders. But still, it is apparent that we do need at least two people (the waiter and the cook) to run a restaurant like that. Can you please explain how does the analogy relate to the chat client problem? – Viplav Kumar Feb 21 '19 at 10:22
  • So as soon as the task that interrupted the "wait for messages" finishes, we continue the "wait for messages" until another interrupt (maybe signaled via a boolean flag) takes place to process another task. That's what you meant right? – Viplav Kumar Feb 21 '19 at 10:43
  • "And it can back later on and check if input is waiting for it.", who will be responsible to register the input when it arrives if my program was busy doing other important stuffs? I can tell you exactly the thing going on in my head right now. I'm imagining the input as a tennis ball, and the chat app as a person who's supposed to catch it. If the catcher is busy say, tying his laces, won't the ball just hit him and bounce back? – Viplav Kumar Feb 21 '19 at 11:08
  • @ViplavKumar Sure, if you have a single thread, and that thread is busy with other things, then your program "freezes". You often see that when people dont understand that they should *not* do any real work on the Swing event dispatcher thread. That thread is solely responsible for "delivering" UI events, such as button clicks, ... when people now do compute intensive things within the context of that thread ... then the whole UI freezes. That is the point: such a single threaded architecture very much relies on you following certain patterns. – GhostCat Feb 21 '19 at 12:03
  • 1
    I won't pretend like I understood everything entirely but your answer did help. Accepting the answer. Thanks! – Viplav Kumar Feb 21 '19 at 12:08