Problem to run thread again
Dear all,
I have a thread, that should wake up when I call the getSomething() method and after the method was called it should return the value and interrupt() again.
I do it so:
publicclass GeneratorThreadimplements Runnable{
private Thread thread;
private GeneratorThread(){
thread =new Thread(this);
thread.setDaemon(true);
thread.start();
}
publicvoid run(){
while (!Thread.currentThread().interrupted()){
doSomething();
Thread.currentThread().interrupt();
}
publicint getSomething(){
return value;
}
privatestatic GeneratorThread inst;
publicstatic GeneratorThread getInstance(){
if (inst ==null) inst =new GeneratorThread();
return inst;
}
}
}
My problem: doSomething method will be executed once as I call GeneratorThread.getInstance.getSomething();
But I want the method run will be executed each time, I call getSomething() method and return a value.
Thanks in advance.
[2110 byte] By [
flexeda] at [2007-10-3 3:49:43]

Solution would be:
(1)Don't use thread. Use a simple plain method instead.
or,
(2)Recreate the thread and call its start() each time when you need it.
By the way, start()ing the thread in the constructor is one of bad practices in Java thread programming because you can't predict the exact timing of completion of the object construction.
And in your while loop, simple boolean would suffice instead of generating/checking an exception.
hiwaa at 2007-7-14 21:47:02 >

Your GeneratorThread object will only execute the while loop in its run() method once - after doSomething() returns, the thread will interrupt itself and so terminate the loop. If you want the thread to wait until getSomething is called then you should use wait()/notify() eg.
boolean somethingAvailable = false
public void run() {
while (!Thread.interrupted()) {
doSomething();
synchronized(this) {
try {
while (!somethingAvailable)
wait();
}
catch(InterruptedException ex) { break; }
}
}
public getSomething() {
// whatever
synchronized(this) {
somethingAvailable = true;
notify();
}
}
BTW interrupted() is a static method that always applies to the current thread so you don't need to use Thread.currentThread().interrupted(), but just Thread.interrupted(). This is important to know because people do things like t.sleep() or t.interrupted() and the code looks like it is doing something to Thread t when in fact it is doing something to the current thread.
> And in your while loop, simple boolean would suffice
> instead of generating/checking an exception.
Thread.interrupt doesn't generate an exception, it simply sets a flag that can be checked using interrupted/isInterrupted and which is checked by certain library methods. It is the library methods that will generate an InterruptedException if needed.
> > And in your while loop, simple boolean would
> suffice
> > instead of generating/checking an exception.
>
> Thread.interrupt doesn't generate an exception, it
> simply sets a flag that can be checked using
> interrupted/isInterrupted and which is checked by
> certain library methods. It is the library methods
> that will generate an InterruptedException if needed.
Thanks.
hiwaa at 2007-7-14 21:47:02 >

> By the way, start()ing the thread in the constructor is one of bad practices in Java thread programming because you can't predict the exact timing of completion of the object construction.
But then doing something likeThread t = new Thread() {public void run() {.....}};
t.start();
suffers from the same problem, doesn't it?
Why Thread.start() being synchronized doesn't not help?
> > By the way, start()ing the thread in the
> constructor is one of bad practices in Java thread
> programming because you can't predict the exact
> timing of completion of the object construction.
>
> But then doing something like> Thread t = new Thread() {public void run() {.....}};
> t.start();
>
> suffers from the same problem, doesn't it?
The problem is that the superclass constructor executes before a subclass constructor (or non-default initialization of any subclass fields). So if you invoke "new Thread(this).start()" and the subclass overrides run() then the new thread can start executing the subclass run() method and access the subclass field before they have been properly initialized. The basic rule here is "don't do that" or else make sure the class isn't subclassed.