Some questions on simple client server socket app

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 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?

1. 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?

1. 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开发者_如何学JAVA 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.

The Sending & receiving works fine because you are using a swing application. a swing app is started as a thread & any actions performed are a part of the EventListener thread (i'm not quite sure of the exact name of the thread though)..

you have a while loop runnung in a thread & whenever a user wants to send something to the server it uses the eventlistener thread to do the job.. Thats why you don't see the program lagging..

It could also be that the transfer isn't too large to take up time.

if you need to build thread access control you should try reading about ReentrantLocks, these classes come as part of JDK. i;d suggest you read Java Concurrency In practice to get a good understanding on java threading.

some links to help you with this 1. ReentrantLocks 2. Java Concurrency in Practice