Regarding non-static interrupt() and join() methods.

[ven jovovich]

Hi all,
The following code is from the Java Tutorials:

public class SimpleThreads {

    // Display a message, preceded by
    // the name of the current thread
    static void threadMessage(String message) {
        String threadName =
            Thread.currentThread().getName();
        System.out.format("%s: %s%n",
                          threadName,
                          message);
    }

    private static class MessageLoop
        implements Runnable {
        public void run() {
            String importantInfo[] = {
                "Mares eat oats",
                "Does eat oats",
                "Little lambs eat ivy",
                "A kid will eat ivy too"
            };
            try {
                for (int i = 0;
                     i < importantInfo.length;
                     i++) {
                    // Pause for 4 seconds
                    Thread.sleep(4000);
                    // Print a message
                    threadMessage(importantInfo[i]);
                }
            } catch (InterruptedException e) {
                threadMessage("I wasn't done!");
            }
        }
    }

    public static void main(String args[])
        throws InterruptedException {

        // Delay, in milliseconds before
        // we interrupt MessageLoop
        // thread (default one hour).
        long patience = 1000 * 60 * 60;

        // If command line argument
        // present, gives patience
        // in seconds.
        if (args.length > 0) {
            try {
                patience = Long.parseLong(args[0]) * 1000;
            } catch (NumberFormatException e) {
                System.err.println("Argument must be an integer.");
                System.exit(1);
            }
        }

        threadMessage("Starting MessageLoop thread");
        long startTime = System.currentTimeMillis();
        Thread t = new Thread(new MessageLoop());
        t.start();

        threadMessage("Waiting for MessageLoop thread to finish");
        // loop until MessageLoop
        // thread exits
        while (t.isAlive()) {
            threadMessage("Still waiting...");
            // Wait maximum of 1 second
            // for MessageLoop thread
            // to finish.
            t.join(1000);
            if (((System.currentTimeMillis() - startTime) > patience)
                  && t.isAlive()) {                                         // line 0
                threadMessage("Tired of waiting!");
                t.interrupt();                                                // line 1
                // Shouldn't be long now
                // -- wait indefinitely
                t.join();                                                       // line 2
            }
        }
        threadMessage("Finally!");
    }
}

Please tell me whether I am getting this correctly:
Supposing that the condition of "line 0" is always true, thread "t" will be interrupted at "line 1".
Now, we are doing "t.join()" on "line 2" so that the exception ALWAYS gets handled (caught)
and "I wasn't done!" always gets printed before "Finally!", right? If we commented out "line 2"
then "Finally!" might have been printed before "I wasn't done!" in some cases. Other than
this there is no point in joining a thread that has been interrupted.

Please let me know if my understanding is correct.

...and one more thing my fellow ranchers, please go through this thread:
https://coderanch.com/t/608307//java/Java

It makes me wonder if it's worth learning java, static methods in interfaces !!! ?? C'mon....
maybe java will be something different with release 12 or 13, they just might drop
curly braces as well (python style).

Regards,
Ven Jovovich.

[Winston Gutkowski]

ven jovovich wrote:It makes me wonder if it's worth learning java, static methods in interfaces !!! ?? C'mon....

Wierdly enough, it's one of the things that I like (AND that I've had reason to want).

The fact is that you can already do it:

public interface SomeInterface {
   ...
   public static final class Utils {
      public static final someValue someMethod(...) {
         // whatever
      }
   }
}

but it's clumsy.

maybe java will be something different with release 12 or 13, they just might drop curly braces as well (python style).

And where do you think Python got it from?

Winston

[ven jovovich]

Thanks Winston, but could you kindly let me know if what I understood from the code is correct...

it's one of the things that I like (AND that I've had reason to want)

Not that I don't like it, in fact it would be neat to have such a thing but what I meant was: by
defining a method in an interface, we are actually changing the definition of what an interface
is. Don't you think this is a huge deviation from what we currently know / understand? It's like
relearning what an interface is. After a few more releases we might have to relearn
what a class is ;)

And where do you think Python got it from?

Where?

Regards,
Ven Jovovich.

[Jeff Verdegan]

ven jovovich wrote:they just might drop
curly braces as well (python style).

By all the gods and devils there may be, I hope not. Giving semantics to the amount of whitespace? Ick.

[Steve Luke]

ven jovovich wrote:Please tell me whether I am getting this correctly:
Supposing that the condition of "line 0" is always true, thread "t" will be interrupted at "line 1".
Now, we are doing "t.join()" on "line 2" so that the exception ALWAYS gets handled (caught)
and "I wasn't done!" always gets printed before "Finally!", right? If we commented out "line 2"
then "Finally!" might have been printed before "I wasn't done!" in some cases.

RIght.

Other than this there is no point in joining a thread that has been interrupted.

I don't think I agree with that. In fact, just interrupting a Thread doesn't ensure it will end soon. The Thread has to respond to the interrupt, and even so it may take significant amount of time to clean up after itself. So if the task in the current Thread needs to wait for the other Thread to complete (interrupted or not) a join() is a good thing to do make sure the other Thread completed in an orderly fashion.

[ven jovovich]

In fact, just interrupting a Thread doesn't ensure it will end soon. The Thread has to respond to the interrupt, and even so it may take significant amount of time to clean up after itself.

Thanks a ton, that explains this:

class X implements Runnable {
	public void run() {
		for (int i = 0; i < 100; i++) {
			System.out.println("hi, " + i +" from meth | " 
							+ Thread.currentThread().getName());
		}
		System.out.println("end of run");
	}
}

class B {
	public static void main(String[] args) throws InterruptedException {
		Thread t = new Thread(new X());
		t.setPriority(Thread.MIN_PRIORITY);
		t.start();
		Thread.sleep(1);
		t.interrupt();
		System.out.println("t interrupted?: " + t.isInterrupted());
	}
}

Output:

hi, 0 from meth | Thread-0
hi, 1 from meth | Thread-0
t interrupted?: true
hi, 2 from meth | Thread-0
hi, 3 from meth | Thread-0
<...continues...>
hi, 97 from meth | Thread-0
hi, 98 from meth | Thread-0
hi, 99 from meth | Thread-0
end of run

So even though my thread (main thread) interrupts another thread, there is no guarantee that the execution of the other thread will stop?

Regards,
Ven Jovovich.

[Steve Luke]

ven jovovich wrote:So even though my thread (main thread) interrupts another thread, there is no guarantee that the execution of the other thread will stop?

Correct. And there is no way to guarantee that another Thread will stop (safely). The code in the other thread has to cooperate either checking for the interrupt status of the thread (Thread.interrupted() or currentThread.isInterrupted() depending on intent) and uses interruptable APIs whenever blocking. A common idiom is to use interruption in conjunction with a state variable so your code knows when an interrupt was intended for ending the task as opposed to being accidental:

class StoppableTask implements Runnable
{
    private volatile boolean shouldStop = false;
    private volatile Thread runningThread;
    
    public void run()
    {
        this.runningThread = Thread.currentThread();
        
        //notice stop check in loop
        for (int i = 0; i < 100 && !isStopped(); i++)
        {
            System.out.println("hi, " + i +" from meth | " 
                + Thread.currentThread().getName());
            
            /* sleep, but respond to interruption, keep sleeping if
             * interrupted but not stopped.
             */    
            long wakeTime = System.currentTimeMillis() + 100;
            while (!isStopped() && System.currentTimeMillis() < wakeTime)
            {
                try
                {
                    sleepUntil(wakeTime);
                }
                catch (InterruptedException ie)
                {
                    if (!shouldStop)
                    {
                        System.err.println("Unexpected interruption, gonna "
                            + "sleep again.");
                    }
                }
            }
        }
        
        System.out.println("End of run");
        this.runningThread = null;
     }
    
    private void sleepUntil(long timeToWake) throws InterruptedException
    {
    	long sleepTime = timeToWake - System.currentTimeMillis();
    	Thread.sleep(sleepTime);
    }
     
     public void stop()
     {   //Tell task it should end
         shouldStop = true;
         
         //If task is running, interrupt it so it knows to stop now
         if (runningThread != null)
         {
             runningThread.interrupt();
         }
     }
     
     public boolean isStopped()
     {
    	 return shouldStop;
     }
 }
 
 public class Runner
 {
     public static void main(String[] args) throws InterruptedException {
        StoppableTask task = new StoppableTask();
        
        Thread runner = new Thread(task);
        runner.start();

        Thread.sleep(200);
        System.out.println("Simulate a spurious interrupt, task shouldn't stop.");
        runner.interrupt();
        
        Thread.sleep(500);
        System.out.println("Actually stop the task.");
        task.stop();
        
        System.out.println("Waiting for task to complete...");
        runner.join();
        
        System.out.println("My work here is done.");
	}
}

hi, 0 from meth | Thread-0
hi, 1 from meth | Thread-0
Simulate a spurious interrupt, task shouldn't stop.
Unexpected interruption, gonna sleep again.
hi, 2 from meth | Thread-0
hi, 3 from meth | Thread-0
hi, 4 from meth | Thread-0
hi, 5 from meth | Thread-0
hi, 6 from meth | Thread-0
Actually stop the task.
Waiting for task to complete...
End of run
My work here is done.

[Winston Gutkowski]

ven jovovich wrote:Thanks a ton, that explains this:...

At the risk of getting flamed by Threading nuts, and Steve's excellent advice notwithstanding, I'd add this personal opinion:
Java has (deliberately) made multi-threading very easy compared to a lot of other languages; but this apparent "simplicity" comes at the price of people giving it the old Harvard Try before they're ready for it.

The fact is that, like reflection (and a few other things) that Java allows, it needs to be approached with caution. Unless you work in a very specialized environment, the amount of time you spend writing multi-threaded programs is likely to be pretty low.

Writing them also involves a lot of side issues that Java doesn't cover as well - the most obvious of which is testing: Threaded programs can be absolute swines to test properly without getting into the world of "Bots" (and sometimes even then).

So, if this is a learning exercise, don't let me stop you - it's all good stuff - just be sure that you know what you're getting into if you plan on making it your "way of life".

Winston

[Jeff Verdegan]

Winston Gutkowski wrote:The fact is that, like reflection (and a few other things) that Java allows, it needs to be approached with caution. Unless you work in a very specialized environment, the amount of time you spend writing multi-threaded programs is likely to be pretty low.

I agree with everything you said except this. Okay, so I kind of agree with the actual statement, but I don't agree with what it seems to imply. The amount of time I spend writing actually writing multithreading code or using reflection is low as a percentage of my total coding effort. That part is true.

However, it seems to imply that, A) Since it's not a large fraction of our total development effort, that implies it's not used in many applications, and B) Since it's not a large fraction of our development effort, it's not something we need to spend a lot of time understanding. I disagree strongly with both of those implications. Multithreading and reflection have both come into play in every project I can ever remember working on. Even if they occupy only a little bit of the code, that code still has to run correctly. Since both of those concepts have their own quirks that can make them tricky to use correctly--and especially because that code isn't a major fraction of our total development effort--we need to make sure we understand them properly so that when we are spending that small fraction of our time on them, we do it correctly.

And even if we're not actually writing multithreading code or reflective code, chances are we're interacting with it, so we still have to be acutely aware of the rules.

I'm pretty sure you didn't actually mean either of the implications I read into what you said, but I thought someone might take it that way, and as a "threading nut", I had to put my two cents in.

[Winston Gutkowski]

Jeff Verdegan wrote:However, it seems to imply that, A) Since it's not a large fraction of our total development effort, that implies it's not used in many applications, and B) Since it's not a large fraction of our development effort, it's not something we need to spend a lot of time understanding. I disagree strongly with both of those implications.

That wasn't my intent (especially B). I would, however, say that I tend to think of both as techniques of last resort (especially reflection); so if you do decide to use them, you'd better be prepared to defend the choice.

I think you know me well enough to know that I'd never say that anyone shouldn't learn new techniques; my advice was more on the lines of "understand before you use" and "know when (and, probably more importantly, when not) to use". For example: using reflection to save yourself typing (or thinking) is poor practise as far as I'm concerned.

I'm pretty sure you didn't actually mean either of the implications I read into what you said, but I thought someone might take it that way, and as a "threading nut", I had to put my two cents in.

Yeah. I knew I'd run into at least one.

Winston

[Jeff Verdegan]

Winston Gutkowski wrote:
I think you know me well enough to know that I'd never say that anyone shouldn't learn new techniques

Of course.

my advice was more on the lines of "understand before you use" and "know when (and, probably more importantly, when not) to use".

Always sound advice.

Both those tools definitely have their place, but there are also a ton of places that don't belong to them but that the unwary will try to shoehorn them into.