Reyada Wolak wrote:if you run S.java and start pressing the button, you will see:
That means the method is not exit and another thread start execute it again.
That is correct. When a Thread wait()s on an object, it releases the lock on the object so that other threads can gain the lock. Why is this important? The only normal way out of a wait() is through the notify(). notify() must be called from another thread, and can only be called inside a synchronized block. Since you never call notify() none of your threads come out of the wait() - and you have what is called deadlock - which will eventually eat resources as you will generate a bunch of threads that can't end.
If you replace wait() with Thread.sleep() it works as expected:
On the other hand i need to use wait() and not sleep() in my case.
K. Tsang wrote:And the JFrame is Q class is really pointless - just makes thing annoying.
Sorry, I was only trying to put the same code as in my application.
K. Tsang wrote:what is the Q class waiting for?
Steve Luke wrote:Why do you need to use wait()?
I'm developing an application that reads the logs from the output (shell) of a native application. I'm waiting until specific line is displayed (output) and then I use a notify() to release the synchronized function.
Sounds like you might be using the wrong paradigm. Instead of using a bunch of runnable threads that have to wait for a specific line, you might think about using an event-based model.
1) Generate a Blocking Queue your producer (whoever would have been reading the output and notify()ing the waiting thread) can reach. When it gets to the point where it needs to trigger the task (the output you are looking for is reached), it adds an 'Event' to the Queue.
2) Generate a single Thread ('Event Thread') which listens to the Blocking Queue for an event. When an event comes into the Queue it dispatches it to a 'Task' or 'Listener'.
3) The 'Task' or 'Listener' does the work for that particular event.
This way your tasks are run in the same Thread - no synchronization issues, and one can't start until the previous finishes - just like you want. It simplifies the triggering, reduces the number of overall threads, and scales pretty well to many events/event types and listeners/tasks.
If that sounds familiar, it should, it is how the AWT/Swing 'Event-Dispatch-Thread' works, and is a good model for waiting for specific events to occur.
I tried to find a way to implement your suggestion without success. I don't know a lot about 'Event-Dispatch-Thread'. I would really appreciate if you give me an example or a link to a tutorial on how to do this.
On the other hand, I faced a lot of problems in using PipedInputStream/PipedOutputStream since they are *sometimes* start to consume a lot of CPU in idle cases. So I remove them and use wait()/notify() to replace the waitForAnswer() function.
I couldn't make it works.
I appreciate your comments
Sorry for the late reply. Yes I do have an example. This is a pretty simplified version but it should get the point across, I hope:
First, this is an interface for the type(s) of events to handle
Another interface to handle tasks to be done when the event occurs:
The 'meat' of the example is an 'EventConsumer' which
1) has an Event Consumer Thread that will execute all the Tasks in
2) has methods to trigger an Event from an external source
3) has methods to register Tasks to do in case of an Event.
Now time to test it. A simple task to do (QTask) which pretends to work
And a GUI that has a button to trigger the tasks (kinda silly I know, but just a sample on usage)