I'm trying to work on the famous dining philosophers and its quite finished but I'm having a quite hard time trying to interrupt threads.
so as you know in this problem we have 5 threads (philosophers) and the user set an experiment time at which the experiment will end.
worth noticing that I looked multiple answers on StackOverflow.
The first one is from #Konrad Reiche How do you kill a Thread in Java?
/Stackoverflow link
In that particular post, people have stated that using volatile boolean as a flag might work out but I'm afraid that it is stated in the exercise paper that I cant use the volatile boolean to interrupt a thread but I can use it for other purposes. (studying exercise).
The second one is Thread interrupt() does not interrupt thread/Stackoverflow link
yet nothing really helped!.
I will try to provide the necessary code and I hope someone would just point out my mistake/s.
the class Philosopher is public and extends Thread!.
1)First attempt:(might get rejected by the professor if he doesn't want us to use volatile boolean as flag!)
when using volatile boolean like this it works:
private volatile boolean isNotStopped=true;
#Override
public void stopPhilosopher() {
System.out.printf("\n%s will stop.\n",selfPhilosopher.getName());
selfPhilosopher.interrupt();
isNotStopped=false;
}
#Override
public void run() {
while (isNotStopped){//selfPhilosopher is a thread equals to this!.
try {
think();
eat();
} catch (InterruptedException e) {//somehow this was never triggered!.
System.out.printf("%s was interrupted.\n",selfPhilosopher.getName());
}finally {//in the finally block i always get RUNNER, FALSE
System.out.printf("the %s is %s and is interrupted %b.\n", selfPhilosopher.getName(),selfPhilosopher.getState(), selfPhilosopher.isInterrupted());
}
}
}
[UPDATE] on Second attempt:[WORKING]
replacing selfPhilosopher.isInterrupted() with Thread.currentThread().isInterrupted() didn't make any difference as selfPhilosopher=this;
yet I was getting "will stop" from the stopPhilosopher() method but the threads seem to be like zombies keep coming back to life :(
due to the fact that I'm pretty convinced by the opinion of #Konrad Reiche from the first reference provided and the answer of #Nathan Hughes I will stick with using the boolean flag provided by the java isInterrupted() instead of using a volatile flag.
#Override
public void stopPhilosopher() {
System.out.printf("\n%s will stop.\n",selfPhilosopher.getName());
selfPhilosopher.interrupt();
}
#Override
public void run() {
while (!selfPhilosopher.isInterrupted()){//selfPhilosopher is a thread equals to this!.
try {
think();
eat();
} catch (InterruptedException e) {//somehow this was never triggered!.Now it works.
System.out.printf("%s was interrupted from catch clause!..\n",selfPhilosopher.getName());
selfPhilosopher.interrupt();
}
}
}
OUTPUT:
Philosopher2 in seat nr: 2 was interrupted from catch clause!..
When an InterruptedException is thrown, the interrupt flag is cleared. That means the next check your loop makes will indicate the thread is not interrupted and the thread will keep on running. That's what you're seeing when your finally block prints out false for the interrupt flag.
This is described in the API doc for the sleep method:
InterruptedException - if any thread has interrupted the current thread. The interrupted status of the current thread is cleared when this exception is thrown.
Add this line to the block where you catch an InterruptedException:
Thread.currentThread().interrupt(); // restores interrupt flag
First of all: I favour the volatile boolean flag over isInterrupted(). It is clear, concise and idiomatically established. The necessary structure for isInterrupted() depends more on details (e.g. try/catch in your case because there seems to be a Thread.sleep (or something similar) declaring InterruptedException).
Since try/catch InterruptedException in your example is within the while-loop the interrupt is consumed and need to be resend to selfPhilosopher (which looks a bit dubious). To avoid this put the while-loop into a surrounding try-catch:
try {
while (!selfPhilosopher.isInterrupted()) {
think();
eat();
}
} catch (InterruptedException e) {
System.out.printf("%s was interrupted from catch clause!..\n",selfPhilosopher.getName());
// not necessary anymore: selfPhilosopher.interrupt();
}
The volatile boolean flag would not need resending and could be used in both constellations (while surrounding try/catch as well as while within try).
Additionally: Suppose your class implements Runnable and is not extending Thread then you also need to take care of setting selfPhilosopher at the beginning of run (and nowhere else).
Related
First of all, I think that all my problems could be more or less solved if I made my method which incurs in a race condition of the type synchronized. I cant use it, because I want to be "manually" able to check if there is a Thread currently using the method, put it to wait until the previous thread finishes and then manually awaken it/notify so the new thread can execute the method.
I am new to Threading in general and Java threading in particular. Any suggestion would be much appreciated.
**Problem**:
I am trying to start a bunch of threads of the same class.
Below you can see its run method.
#Override
public void run() {
if (!lck.tryLock()) { //sort of mutex
System.out.println(this.toString() + "waiting");
try {
synchronize();
} catch (InterruptedException ex) {
}
}
methodRaceCondition(this);
condition=true; //variable i am tryng to use to make the method below "awaken" the waiting threads.
lck.unlock();
}
I created a Lock (ReentrantLock) so I can check if there is a thread currently using the method with critical section -so i avoid race condition.
If there is one thread using this methodRaceCondition, I want to make the newcomer thread wait. I used a new method for it, bc as far as I know you can just make a thread wait and notify inside a synchronized method (and, I cant/dont want to use it, see above), so I created this synchronized method.
public synchronized void synchronize() throws InterruptedException {
while(!condition) {
wait();
}
notifyAll(); //
}
Here, what I (unseccesfully try to) do is make a thread wait (in case a thread N helds the lock), once the thread N is done, in the run method i want to make the while condition true, so that all the threads waiting are notifie/awaken.
However, if I run it, a deadlock happens. I am just not able to awaken all the waiting threads! and the program cant finish.
I cant figure out how to solve this. I hope I am being clear enough.
UPLOAD
My solution, so far, using semaphores, as a poster suggested. I was stuck in this idea of using locks and monitors, etc. Semaphores look enough. It does the job, Suggestions very welcome.
#Override
public void run() {
//synchronization, if busy, show that the method is occupied and wait.
if (!semaphoreSinc.tryAcquire()) {
System.out.println(this.toString() + "waiting");
try {
semaphoreSinc.acquire();
} catch (InterruptedException ex) {
Logger.getLogger(Socio.class.getName()).log(Level.SEVERE, null, ex);
}
}
//mutex to prevent race condition
try {
mutex.acquire();
} catch (InterruptedException ex) {
Logger.getLogger(Socio.class.getName()).log(Level.SEVERE, null, ex);
}
methodRaceCondition(this);
//done, let other possible threads access it
mutex.release();
//awaken waiting threads
semaphoreSinc.release();
}
QUESTION:
Would it be possible to replicate this behaviour with monitors?
Why invoke the method Thread.currentThread.interrupt() in the catch block?
This is done to keep state.
When you catch the InterruptedException and swallow it, you essentially prevent any higher-level methods/thread groups from noticing the interrupt. Which may cause problems.
By calling Thread.currentThread().interrupt(), you set the interrupt flag of the thread, so higher-level interrupt handlers will notice it and can handle it appropriately.
Java Concurrency in Practice discusses this in more detail in Chapter 7.1.3: Responding to Interruption. Its rule is:
Only code that implements a thread's interruption policy may swallow an interruption request. General-purpose task and library code should never swallow interruption requests.
I think this code sample makes things a bit clear.
The class which does the job :
public class InterruptedSleepingRunner implements Runnable {
#Override
public void run() {
doAPseudoHeavyWeightJob();
}
private void doAPseudoHeavyWeightJob() {
for (int i = 0; i < Integer.MAX_VALUE; i++) {
// You are kidding me
System.out.println(i + " " + i * 2);
// Let me sleep <evil grin>
if (Thread.currentThread().isInterrupted()) {
System.out.println("Thread interrupted\n Exiting...");
break;
} else {
sleepBabySleep();
}
}
}
protected void sleepBabySleep() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
}
The Main class:
public class InterruptedSleepingThreadMain {
public static void main(String[] args) throws InterruptedException {
Thread thread = new Thread(new InterruptedSleepingRunner());
thread.start();
// Giving 10 seconds to finish the job.
Thread.sleep(10000);
// Let me interrupt
thread.interrupt();
}
}
Try calling interrupt without setting the status back.
Note:
http://download.oracle.com/javase/7/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html
How do I stop a thread that waits for long periods (e.g., for input)?
For this technique to work, it's critical that any method that catches an interrupt exception and is not prepared to deal with it immediately reasserts the exception. We say reasserts rather than rethrows, because it is not always possible to rethrow the exception. If the method that catches the InterruptedException is not declared to throw this (checked) exception, then it should "reinterrupt itself" with the following incantation:
Thread.currentThread().interrupt();
This ensures that the Thread will reraise the InterruptedException as soon as it is able.
I would consider it a bad practice or at least a bit risky.
Usually higher level methods do not perform blocking operations and they will never see InterruptedException there. If you mask it in every place you perform interruptible operation, you will never get it.
The only rationale for Thread.currentThread.interrupt() and not raising any other exception or signaling interrupt request in any other way (e.g. setting interrupted local variable variable in a thread's main loop) is the situation where you really can't do anything with the exception, like in the finally blocks.
See Péter Török's answer, if you want to better understand implications of the Thread.currentThread.interrupt() call.
Refer from java doc
If this thread is blocked in an invocation of the wait(), join(),
sleep(long), then its interrupt status will be cleared and it will
receive an InterruptedException.
If this thread is blocked in an I/O operation, the thread's interrupt
status will be set, and the thread will receive a
ClosedByInterruptException.
If this thread is blocked in a Selector then the thread's interrupt
status will be set and it will return immediately from the selection
operation.
If none of the previous conditions hold then this thread's interrupt
status will be set.
So, if you change the sleepBabySleep() method in #Ajay George Answer to I/O operation or just a sysout, you don't have to set the status back to stop the program. (BTW, they don't even throw InterruptedException)
Just like #Péter Török said => This is done to keep state. (And particular for method that will throw InterruptedException)
This question already has answers here:
Why should wait() always be called inside a loop
(11 answers)
Closed 7 years ago.
I've tried reading some answers to similar questions here (I always do that) but did not find (or did not understand?) the answer to this particular issue.
I am implementing a fairly simple consumer-producer class, which receives elements to a list from a different thread and consumes them repeatedly. The class has the following code:
public class ProduceConsume implements Runnable
{
LinkedList<Integer> _list = new LinkedList<Integer>();
public synchronized void produce(Integer i)
{
_list.add(i);
notify();
}
public void run()
{
while(true)
{
Integer i = consume();
// Do something with the integer...
}
}
private synchronized Integer consume()
{
if(_list.size() == 0)
{
try
{
wait();
}
catch(InterruptedException e){}
return _list.poll();
}
}
}
The problem is - it usually works fine, but sometimes, the execution gets to
return _list.poll();
with the list still empty. I can't wrap my head around it - am I doing something terribly wrong? Shouldn't the runnable thread, which repeatedly tries to poll detect a zero length list, wait, and be awakened only after the producer method is done, hence making the list non-empty?
Nothing else "touches" the class from the outside, except for calls to produce. No other threads are synchronized on the runnable class.
By the way, for several reasons, I wish to use my own variant and not classes such as CopyOnWriteArrayList, etc.
Thanks! Any help would be greatly appreciated.
P.S - I have not used the wait-notify many times, but when I did, in the past, it worked. So if I apologize if I made some huge stupid error!
As the Javadoc for Object.wait states
As in the one argument version, interrupts and spurious wakeups are possible, and this method should always be used in a loop:
synchronized (obj) {
while (<condition does not hold>)
obj.wait();
... // Perform action appropriate to condition
}
Additionally, you shouldn't ignore an exception like InterruptedException. This will look like a spurious wake up and as you say produces an error.
private synchronized Integer consume() {
try {
while (_list.isEmpty())
wait();
return _list.poll();
} catch(InterruptedException e) {
throw new IllegalStateException("Interrupted");
}
}
Since wait releases the lock you can't reason based on conditions tested before it started waiting, assuming the condition must have changed once wait is exited is not valid. You need to call wait in a loop, so that once the thread ceases waiting and takes the lock again, it checks that the condition it's waiting for has the expected value:
private synchronized Integer consume()
{
try {
while (_list.size() == 0) {
wait();
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
return _list.poll();
}
From the Oracle tutorial:
Note: Always invoke wait inside a loop that tests for the condition being waited for.
Also it's not safe to assume that just because wait returned that something sent a notification. wait can return even if there is no notification (the spurious wakeup).
It's hard to say what caused what you're seeing without a complete working example.
The linked Oracle tutorial page has a Producer Consumer example you might want to look at.
I just want to get know about if this thread is interrupting or not if I'm doing it right?
please give me hint if I'm wrong
public void run(){
int i;
while(!Thread.currentThread().isInterrupted()){
for(i=1;i<=100;i++){
System.out.println("THREAD VALUE AFTER 1 SECOND IS: "+i);
if(i==3){
Thread.currentThread().interrupt();
gotoInform();
break;
}
try{
Thread.currentThread().sleep(1000);////to sleep the Thread for 1 Second (1000ms)
}
catch(Exception e){
System.out.printf("Error"+e);
}
}
}
This is wrong, because if sleep finds that the thread is interrupted, it will throw an InterruptedException and clear the interrupted flag. You then swallow that exception, suppressing any record that the thread was ever interrupted. Instead, you should write something more like this:
public void run(){
for(int i=1;i<=100;i++){
System.out.println("THREAD VALUE AFTER 1 SECOND IS: "+i);
if(i==3){
Thread.currentThread().interrupt();
gotoInform();
break;
}
try{
Thread.currentThread().sleep(1000);
}
catch(final Exception e){
e.printStackTrace();
if(e instanceof InterruptedException) {
// just in case this Runnable is actually called directly,
// rather than in a new thread, don't want to swallow the
// flag:
Thread.currentThread().interrupt();
}
return;
}
}
}
(Note: I'm assuming that this is not "real" code, but rather, that you're just trying to learn how thread interruption works. In "real" code, you should almost never need to interrupt the current thread in this way.)
As mentioned before, a thread interrupting itself is pointless (unless used to re-interrupt itself after catching an InterruptedException) . You're basically using the thread's internal interrupted flag as a conditional variable here - which while it may work is not at all what it's supposed to be used for and will be confusing to anyone else who would need to read your code. Use a loop counter instead as suggested above to make the code much cleaner.
Also, your statement:
System.out.println("THREAD VALUE AFTER 1 SECOND IS: "+i);
is erroneous as it will execute immediately the first time through the loop (when the time is closer to zero seconds).
I just want to get know about if this thread is interrupting or not if I'm doing it right?
#ruakh is correct that it is always a good idea to re-interrupt a thread once InterruptedException is thrown.
However, if the goal of your code is to self-interrupt and no other threads will interrupt the running thread, then you will never get to the sleep() call since break; is called after the thread is interrupted.
If the thread is always just self interrupted then I would just use a flag. Something like:
boolean done = false;
while (!done) {
...
if(i==3){
done = true;
...
}
}
Even though you interrupt your thread, you then call gotoInform() which may call wait()or sleep() itself and cause an InterruptedException. You'll need to make sure that code behaves well and re-interrupts the thread if so.
I have a method that I would like to call. However, I'm looking for a clean, simple way to kill it or force it to return if it is taking too long to execute.
I'm using Java.
to illustrate:
logger.info("sequentially executing all batches...");
for (TestExecutor executor : builder.getExecutors()) {
logger.info("executing batch...");
executor.execute();
}
I figure the TestExecutor class should implement Callable and continue in that direction.
But all i want to be able to do is stop executor.execute() if it's taking too long.
Suggestions...?
EDIT
Many of the suggestions received assume that the method being executed that takes a long time contains some kind of loop and that a variable could periodically be checked.
However, this is not the case. So something that won't necessarily be clean and that will just stop the execution whereever it is is acceptable.
You should take a look at these classes :
FutureTask, Callable, Executors
Here is an example :
public class TimeoutExample {
public static Object myMethod() {
// does your thing and taking a long time to execute
return someResult;
}
public static void main(final String[] args) {
Callable<Object> callable = new Callable<Object>() {
public Object call() throws Exception {
return myMethod();
}
};
ExecutorService executorService = Executors.newCachedThreadPool();
Future<Object> task = executorService.submit(callable);
try {
// ok, wait for 30 seconds max
Object result = task.get(30, TimeUnit.SECONDS);
System.out.println("Finished with result: " + result);
} catch (ExecutionException e) {
throw new RuntimeException(e);
} catch (TimeoutException e) {
System.out.println("timeout...");
} catch (InterruptedException e) {
System.out.println("interrupted");
}
}
}
Java's interruption mechanism is intended for this kind of scenario. If the method that you wish to abort is executing a loop, just have it check the thread's interrupted status on every iteration. If it's interrupted, throw an InterruptedException.
Then, when you want to abort, you just have to invoke interrupt on the appropriate thread.
Alternatively, you can use the approach Sun suggest as an alternative to the deprecated stop method. This doesn't involve throwing any exceptions, the method would just return normally.
I'm assuming the use of multiple threads in the following statements.
I've done some reading in this area and most authors say that it's a bad idea to kill another thread.
If the function that you want to kill can be designed to periodically check a variable or synchronization primitive, and then terminate cleanly if that variable or synchronization primitive is set, that would be pretty clean. Then some sort of monitor thread can sleep for a number of milliseconds and then set the variable or synchronization primitive.
Really, you can't... The only way to do it is to either use thread.stop, agree on a 'cooperative' method (e.g. occassionally check for Thread.isInterrupted or call a method which throws an InterruptedException, e.g. Thread.sleep()), or somehow invoke the method in another JVM entirely.
For certain kinds of tests, calling stop() is okay, but it will probably damage the state of your test suite, so you'll have to relaunch the JVM after each call to stop() if you want to avoid interaction effects.
For a good description of how to implement the cooperative approach, check out Sun's FAQ on the deprecated Thread methods.
For an example of this approach in real life, Eclipse RCP's Job API's 'IProgressMonitor' object allows some management service to signal sub-processes (via the 'cancel' method) that they should stop. Of course, that relies on the methods to actually check the isCancelled method regularly, which they often fail to do.
A hybrid approach might be to ask the thread nicely with interrupt, then insist a couple of seconds later with stop. Again, you shouldn't use stop in production code, but it might be fine in this case, esp. if you exit the JVM soon after.
To test this approach, I wrote a simple harness, which takes a runnable and tries to execute it. Feel free to comment/edit.
public void testStop(Runnable r) {
Thread t = new Thread(r);
t.start();
try {
t.join(2000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
if (!t.isAlive()) {
System.err.println("Finished on time.");
return;
}
try {
t.interrupt();
t.join(2000);
if (!t.isAlive()) {
System.err.println("cooperative stop");
return;
}
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
System.err.println("non-cooperative stop");
StackTraceElement[] trace = Thread.getAllStackTraces().get(t);
if (null != trace) {
Throwable temp = new Throwable();
temp.setStackTrace(trace);
temp.printStackTrace();
}
t.stop();
System.err.println("stopped non-cooperative thread");
}
To test it, I wrote two competing infinite loops, one cooperative, and one that never checks its thread's interrupted bit.
public void cooperative() {
try {
for (;;) {
Thread.sleep(500);
}
} catch (InterruptedException e) {
System.err.println("cooperative() interrupted");
} finally {
System.err.println("cooperative() finally");
}
}
public void noncooperative() {
try {
for (;;) {
Thread.yield();
}
} finally {
System.err.println("noncooperative() finally");
}
}
Finally, I wrote the tests (JUnit 4) to exercise them:
#Test
public void testStopCooperative() {
testStop(new Runnable() {
#Override
public void run() {
cooperative();
}
});
}
#Test
public void testStopNoncooperative() {
testStop(new Runnable() {
#Override
public void run() {
noncooperative();
}
});
}
I had never used Thread.stop() before, so I was unaware of its operation. It works by throwing a ThreadDeath object from whereever the target thread is currently running. This extends Error. So, while it doesn't always work cleanly, it will usually leave simple programs with a fairly reasonable program state. For example, any finally blocks are called. If you wanted to be a real jerk, you could catch ThreadDeath (or Error), and keep running, anyway!
If nothing else, this really makes me wish more code followed the IProgressMonitor approach - adding another parameter to methods that might take a while, and encouraging the implementor of the method to occasionally poll the Monitor object to see if the user wants the system to give up. I'll try to follow this pattern in the future, especially methods that might be interactive. Of course, you don't necessarily know in advance which methods will be used this way, but that is what Profilers are for, I guess.
As for the 'start another JVM entirely' method, that will take more work. I don't know if anyone has written a delegating class loader, or if one is included in the JVM, but that would be required for this approach.
Nobody answered it directly, so here's the closest thing i can give you in a short amount of psuedo code:
wrap the method in a runnable/callable. The method itself is going to have to check for interrupted status if you want it to stop (for example, if this method is a loop, inside the loop check for Thread.currentThread().isInterrupted and if so, stop the loop (don't check on every iteration though, or you'll just slow stuff down.
in the wrapping method, use thread.join(timeout) to wait the time you want to let the method run. or, inside a loop there, call join repeatedly with a smaller timeout if you need to do other things while waiting. if the method doesn't finish, after joining, use the above recommendations for aborting fast/clean.
so code wise, old code:
void myMethod()
{
methodTakingAllTheTime();
}
new code:
void myMethod()
{
Thread t = new Thread(new Runnable()
{
public void run()
{
methodTakingAllTheTime(); // modify the internals of this method to check for interruption
}
});
t.join(5000); // 5 seconds
t.interrupt();
}
but again, for this to work well, you'll still have to modify methodTakingAllTheTime or that thread will just continue to run after you've called interrupt.
The correct answer is, I believe, to create a Runnable to execute the sub-program, and run this in a separate Thread. THe Runnable may be a FutureTask, which you can run with a timeout ("get" method). If it times out, you'll get a TimeoutException, in which I suggest you
call thread.interrupt() to attempt to end it in a semi-cooperative manner (many library calls seem to be sensitive to this, so it will probably work)
wait a little (Thread.sleep(300))
and then, if the thread is still active (thread.isActive()), call thread.stop(). This is a deprecated method, but apparently the only game in town short of running a separate process with all that this entails.
In my application, where I run untrusted, uncooperative code written by my beginner students, I do the above, ensuring that the killed thread never has (write) access to any objects that survive its death. This includes the object that houses the called method, which is discarded if a timeout occurs. (I tell my students to avoid timeouts, because their agent will be disqualified.) I am unsure about memory leaks...
I distinguish between long runtimes (method terminates) and hard timeouts - the hard timeouts are longer and meant to catch the case when code does not terminate at all, as opposed to being slow.
From my research, Java does not seem to have a non-deprecated provision for running non-cooperative code, which, in a way, is a gaping hole in the security model. Either I can run foreign code and control the permissions it has (SecurityManager), or I cannot run foreign code, because it might end up taking up a whole CPU with no non-deprecated means to stop it.
double x = 2.0;
while(true) {x = x*x}; // do not terminate
System.out.print(x); // prevent optimization
I can think of a not so great way to do this. If you can detect when it is taking too much time, you can have the method check for a boolean in every step. Have the program change the value of the boolean tooMuchTime to true if it is taking too much time (I can't help with this). Then use something like this:
Method(){
//task1
if (tooMuchTime == true) return;
//task2
if (tooMuchTime == true) return;
//task3
if (tooMuchTime == true) return;
//task4
if (tooMuchTime == true) return;
//task5
if (tooMuchTime == true) return;
//final task
}