Question

I create threads of class A and each sends a serialized object to a Server using ObjectOutputStream.

The Server creates new Threads B for each socket connection (whenever a new A client connects)

B will call a synchronized method on a Shared Resource Mutex which causes it (B) to wait() until some internal condition in the Mutex is true.

In this case how A can know that B is currently waiting?

Hope this description is clear.

Class Arrangement:

A1--------->B1-------->|       |
A2--------->B2-------->| Mutex |
A3--------->B3-------->|       |

EDIT:
it’s a must to have wait(), notify() or notifyAll(), since this is for an academic project where concurrency is tested.

Answer 1

Normally A would read on the socket, which would “block” (i.e. not return, hang up) until some data was sent back by B. It doesn’t need to be written to deal with the waiting status of B. It just reads and that inherently involves waiting for something to read.

Update So you want A’s user interface to stay responsive. By far the best way to do that is take advantage of the user interface library’s event queue system. All GUI frameworks have a central event loop that dispatches events to handlers (button click, mouse move, timer, etc.) There is usually a way for a background thread to post something to that event queue so that it will be executed on the main UI thread. The details will depend on the framework you’re using.

For example, in Swing, a background thread can do this:

SwingUtilities.invokeAndWait(someRunnableObject);

So suppose you define this interface:

public interface ServerReplyHandler {
    void handleReply(Object reply);
}

Then make a nice API for your GUI code to use when it wants to submit a request to the server:

public class Communications {

    public static void callServer(Object inputs, ServerReplyHandler handler);

}

So your client code can call the server like this:

showWaitMessage();

Communications.callServer(myInputs, new ServerReplyHandler() {
    public void handleReply(Object myOutputs) {

        hideWaitMessage();
        // do something with myOutputs...

    }
});

To implement the above API, you’d have a thread-safe queue of request objects, which store the inputs object and the handler for each request. And a background thread which just does nothing but pull requests from the queue, send the serialised inputs to the server, read back the reply and deserialise it, and then do this:

final ServerReplyHandler currentHandler = ...
final Object currentReply = ...

SwingUtilities.invokeAndWait(new Runnable() {
    public void run() {

        currentHandler.handleReply(currentReply);

    }
});

So as soon as the background thread has read back the reply, it passes it back into the main UI thread via a callback.

This is exactly how browsers do asynchronous communication from JS code. If you’re familiar with jQuery, the above Communications.callServer method is the same pattern as:

showWaitMessage();

$.get('http://...', function(reply) {

    hideWaitMessage();

    // do something with 'reply' 
});

The only difference in this case is that you are writing the whole communication stack by hand.

Update 2

You asked:

You mean I can pass “new ObjectOutputStream().writeObject(obj)” as
“myInputs” in Communications.callServer?

If all information is passed as serialised objects, you can build the serialisation into callServer. The calling code just passes some object that supports serialisation. The implementation of callServer would serialise that object into a byte[] and post that to the work queue. The background thread would pop it from the queue and send the bytes to the server.

Note that this avoids serialising the object on the background thread. The advantage of this is that all background thread activity is separated from the UI code. The UI code can be completely unaware that you’re using threads for communication.

Re: wait and notify, etc. You don’t need to write your own code to use those. Use one of the standard implementations of the BlockingQueue interface. In this case you could use LinkedBlockingQueue with the default constructor so it can accept an unlimited number of items. That means that submitting to the queue will always happen without blocking. So:

private static class Request {
    public byte[] send;
    public ServerReplyHandler handler;
};

private BlockingQueue<Request> requestQueue;

public static callServer(Object inputs, ServerReplyHandler handler) {

    ByteArrayOutputStream byteStream = new ByteArrayOutputStream();
    new ObjectOutputStream(byteStream).writeObject(inputs);

    Request r = new Request();
    r.send = byteStream.toByteArray();
    r.handler = handler;
    requestQueue.put(r);
}

Meanwhile the background worker thread is doing this:

for (;;) {
    Request r = requestQueue.take();

    if (r == shutdown) {
        break;
    }

    // connect to server, send r.send bytes to it
    // read back the response as a byte array:

    byte[] response = ...

    SwingUtilities.invokeAndWait(new Runnable() {
        public void run() {
            currentHandler.handleReply(
                new ObjectInputStream(
                    new ByteArrayInputStream(response)
                ).readObject()
            );
        }
    });
}

The shutdown variable is just:

private static Request shutdown = new Request();

i.e. it’s a dummy request used as a special signal. This allows you to have another public static method to allow the UI to ask the background thread to quit (would presumably clear the queue before putting shutdown on it).

Note the essentials of the pattern: UI objects are never accessed on the background thread. They are only manipulated from the UI thread. There is a clear separation of ownership. Data is passed between threads as byte arrays.

You could start multiple workers if you wanted to support more than one request happening simultaneously.