5 replies to this topic

[Aliii]

Ive read that stop() is deprecated, but its not reacting to interrupt or suspend either.

So I extended an AsyncTask class and overrode some methods.
Ive read that this while( running) magic is like "killing the thread manually".
Is there any better solution? I think that a while looping continuously in the background is not too efficient.

(Plus: could somebody tell me what exactly thread.join() does?
"Blocks the calling thread until a thread terminates, while continuing to perform standard COM and SendMessage pumping."
...yes, sure:))

Thanks!
..................................................
public void stop(){
running= false;
}

public void pause(){
paused= true;
}

public void resume(){
paused= false;
}


@Override
protected String doInBackground(Integer... params) {

running= true;
paused= false;

while(running){

if( paused){
...do nothing
}
else{

....do stuff

}
}

return null;
}

[ApochPiQ]

You should not use boolean variables to signal to a thread; that is subject to race conditions and can easily produce undesirable nondeterministic behavior.

Instead, use a thread synchronization primitive such as a condition variable or semaphore to signal when you want your thread to run. This allows the OS to control the thread properly, and will have the added bonus of making your thread consume no CPU resources when it is not active.

[Antheus]

"Blocks the calling thread until a thread terminates, while continuing to perform standard COM and SendMessage pumping."

That is .Net.

AsyncTask

That is Android.

stop() is deprecated,

And that is JDK/JEE's Thread class.

So the original question mixes some 3 different platforms.


For which of those is the question intended?

Is there any better solution?

For what exactly? Threads are created, they run and then terminate. Stopping or otherwise interferring with them has long been abandoned due to problems it causes.

What are you really trying to accomplish?

[Bacterius]

Threads on every platform already have built-in suspend/resume mechanisms, you should those instead of rolling your own.

For what exactly? Threads are created, they run and then terminate. Stopping or otherwise interferring with them has long been abandoned due to problems it causes.

For very long-running tasks it's important for the user to be able to suspend the process at any given time, and suspend/resume is much better in that respect than destroying and recreating every thread used. If you use the mechanisms provided by your OS (and transparently interfaced by Java) it will work perfectly too.

[e‍dd]

Threads on every platform already have built-in suspend/resume mechanisms, you should those instead of rolling your own.

This isn't a good idea (depending on exactly what you mean by built-in suspend resume mechanisms). It you suspend a thread while it has a lock held, that's a great way to bring the rest of your application to a stand-still.

For very long-running tasks it's important for the user to be able to suspend the process at any given time.

As ApochPiQ said, primitives such as condition variables and semaphores are the things to use.

I agree with what you say about not having to (re)create threads on a regular basis, but the correct way to feed them work is to use queues of tasks or data. Many environments will provide suitable queues out the box, which will use the aforementioned primitives internally. I'm sure this is true of Java, in particular

[Aliii]

Thanks for the answers!

You should not use boolean variables to signal to a thread; that is subject to race conditions and can easily produce undesirable nondeterministic behavior.

Instead, use a thread synchronization primitive such as a condition variable or semaphore to signal when you want your thread to run. This allows the OS to control the thread properly, and will have the added bonus of making your thread consume no CPU resources when it is not active.

Ive found a piece of code that does something like that, but I dont think I can do this with AsyncTask. I dont know what that constructor does(runner = new Thread(this);). However Ive found an AsyncTask.cancel() method that stops the thread just fine(if I handle the interrupt-exception in the run method), but there is no pause/resume method. Is it OK if I declare that pause boolean volatile and do it that way? I guess that will consume CPU too. Or should I save the threads state when I stop it and reload from that when is start it again(resume)? Thanks!


private volatile Thread runner;

public synchronized void startThread(){
if(runner == null){
runner = new Thread(this);
runner.start();
}
}

public synchronized void stopThread(){
if(runner != null){
Thread moribund = runner;
runner = null;
moribund.interrupt();
}
}

public void run(){
while(Thread.currentThread() == runner){
//do stuff which can be interrupted if necessary
}
}