I am writing a simple multithreaded client-server application using sockets, and have a few questions:
1. For the client, is it really necessary to use a separate thread (i.e. of the java Thread class) for receiving data from server?
Many resources I found use the client object to send data (using dataOutputStream) to the server, while employing a single thread specifically to receive data (using dataInputStream) from the server. This is supposedly because I/O streams are blocking by nature, so a single thread of execution shouldn't be able to send data (or do anything else) while waiting for a server message because the program is blocked until something is received.
However, the client I wrote could do sending and receiving without using a separate thread. The code to receive data (i.e. socket.readUTF()) was put in a while loop, and the code to send data (i.e. socket.writeUTF()) was in the actionPerformed() method (to be triggered when user clicked a button). As far as I can tell, while the user did nothing, program execution remained in the while loop, listening for server message. When the user clicks the button, the actionPerformed() method was triggered, "interrupting" the while loop and sending a message. Once done, the program went back to listening. The sending and receiving worked perfectly.
Why then do people use a separate thread?
2. If i decide to use a separate thread for receiving do I need to make the client object a thread as well? Or can I just run the client as an object? I'm asking this because I noticed some people ran the client object as a thread.
I'm not too sure why they did that because as far as I can tell, when you create an object and a thread, they run concurrently (i.e. like two threads would). Since only one object is involved in this case (the client), it shouldn't need to be run as a thread, right? Or am I missing something?
3. Does an object need to acquire the lock in order to access its own method, if that method is synchronized? Here's my situation:
My server is implemented as an object. Session threads are created for each client connection. Each session thread calls the server object's handle() method whenever it receives a client request. The handle method is synchronized, and sends return information to the client.
Apart from the handle() method, the server also has some other methods that send information to each client. These methods can be called at any time through the server's GUI (they are not called by the session threads). While the handle() method is running, I DO NOT want these other methods to run because they may interfere with handle() and mess up the sending protocol. In other words, I want the handle method to finish before these other methods are run.
Can I make these methods synchronized in order to prevent the server object from calling them when the handle method is running, and vice versa? Theoretically the server object would need to wait for the handle's lock to be released before it could call them. I'm just not sure if an object (not thread) would need to acquire the lock on its own synchronized method in order to access it. Hence my question.
Sorry for the lack of brevity, but I wanted to be as clear as possible. Explanations and feedback are very much appreciated.
Thanks in advance.