CODEWITHSUNDEEP
javamultithreading
drop.in.ocean
drop.in.ocean

Reputation: 298

What is real purpose of this wait-notify thread semantics?

I just came across some code which uses wait-notify construct to communicate with thread defined in a class, by its other member-methods. Amusingly, after acquiring lock, all thread does in synchronized scope is timed-wait on same lock (see below snippet). Later, in non-synchronized scope, thread executes its key function (ie '//do something useful1').

My best guess at purpose of this mechanism is, to minimize thread's resource-consumption until call to 'someMethod' is made by other thread. What do experts think? If this is the case, what are better ways of achieving this behavior?

class SomeClass{
    public void run() {
        while (!isShuttingDown){
            try {
                synchronized (SomeClass.class) {
                    SomeClass.class.wait(500);
                }
            } catch (Throwable e) {
                LOGGER.info(SomeClass.class.getSimpleName() + " reaper thread interrupted", e);
            }
            //do something useful1
          }
    }


    public synchronized void someMethod(){
            //do something useful2
             synchronized (SomeClass.class) {
                SomeClass.class.notifyAll();
            }   
                   //do something useful3
    }
}

Upvotes: 0

Views: 501

Answers (2)

Dark Knight
Dark Knight

Reputation: 8347

As described here,

The wait-notify pattern is used in a broad set of cases where one thread needs to tell other threads that some event has occurred. It is commonly used to implement a thread pool or producer-consumer scenario, where a particular thread or threads need to "pick up jobs" created by other threads (in this case, the "event" that has occurred is that a job has arrived for one of the threads to pick up).

Upvotes: 4

Gray
Gray

Reputation: 116888

after acquiring lock, all thread does in synchronized scope is timed-wait on same lock (see below snippet).

Yes, the pattern is strange. Typically I have a loop similar to that (although I always use a private final lockObject) that waits for a small amount of time because I don't want the method to spin -- performing its task too often.

I would have thought that the other method would lock on the same variable and then update the isShuttingDown flag. But doing the other // useful# sections is a strange pattern since there are a number of race conditions with the code that is going to make determining the order of the useful sections impossible.

Upvotes: 1

Related Questions