I am new to java and learning multi-threading. I wrote the following code.
class BackgroundTask implements Runnable {
private int counter = 0;
public int getCounter() {
return counter;
}
public void setCounter(int counter) {
this.counter = counter;
}
#Override
public void run() {
System.out.println("Thread started");
while (true) {
this.setCounter(this.getCounter() + 1);
}
}
}
public class Main {
public static void main(String[] args) {
BackgroundTask bgTask = new BackgroundTask();
Thread bgCount = new Thread(bgTask);
try {
bgCount.start();
System.out.println("counter in background is running");
bgCount.interrupt();
System.out.println(bgTask.getCounter());
} catch (Exception e) {
System.out.println(e.getMessage());
}
}
}
Output of the code:
counter in background is running
0
Thread started
Q.1 why is bgCount.start() executing after the print statement when it is written before it?
Q.2 Why did the thread start after calling the getCounter() method?
Edit: Thanks everyone for all the cool answers, now I understand the concept of threads.
When you do things in two different threads, they are unsynchronized unless you force some kind of synchronization. One thread might execute first or the other thread might or they might interleave in unpredictable ways. That's kind of the point of threads.
Explanation
Q.1 why is bgCount.start() executing after the print statement when it is written before it?
It is not, this is an incorrect conclusion. start() is executed exactly when you have written it. It just does not necessarily mean that the thread immediatly starts. The OS scheduler determines when to start a thread. The only guarantee that you get is that it will eventually start, so maybe now, maybe in a hour, maybe next year. Obviously, in practice it will usually be almost instant. But that does not mean it is executed as the very next thing.
Q.2 Why did the thread start after calling the getCounter() method?
As explained before, the OS scheduler decides. You just had bad luck. Seriously, you have no control over this and should not do any assumptions on this.
Multi-threading
If you have multiple threads and they have a series of operations to execute, the OS scheduler is completely free to decide how to interleave the operations. That also means that not interleaving anything is valid as well.
Lets take a look at an example with thread A and B that have 2 operations to execute each. The following orders of executions are all valid outcomes of the scheduler:
A.1
A.2
B.1
B.2
A.1
B.1
A.2
B.2
A.1
B.1
B.2
A.2
B.1
B.2
A.1
A.2
B.1
A.1
B.2
A.2
B.1
A.1
A.2
B.2
So you must not make any assumptions about when a thread starts and especially not about in which order operations are executed in regards to other threads. It might be fully interleaved, might be sequential, might be partially interleaved, everything could happen.
If you want to take control over the mechanism, the correct tool is synchronization. With that you can tell that you want to wait for a certain thing to happen first in another thread before you continue. A very simple example for your above code would be to wait until bgCount is fully done before continuing to print the count. You can do so by using join():
bgCount.start();
System.out.println("counter in background is running");
bgCount.join(); // waiting until down
System.out.println(bgTask.getCounter());
However, if you do it like that, you defeated the purpose of having a thread in the first place. There is no benefit in computing something in-parallel if you completely block the other thread and wait. Then it is basically just like executing something in the ordinary sequential way.
Related
I'm developing the transformer for Java 6*1) that performs a kind of partial evaluation but let's consider, for simplicity, abstract-syntax-tree interpretation of a Java program.
How to simulate the Thread's behavior by an interpreted program?
At the moment I have in mind the following:
AstInterpreter should implement java.lang.Runnable. It also should rewrite every new-instance-expression of the java.lang.Thread (or its sub-class) replacing the Thread's target (java.lang.Runnable) with the new AstInterpreter instance:
EDIT: more complex examples provided.
EDIT 2: remark 1.
Target program:
class PrintDemo {
public void printCount(){
try {
for(int i = 5; i > 0; i--) {
System.out.println("Counter --- " + i );
}
} catch (Exception e) {
System.out.println("Thread interrupted.");
}
}
}
class ThreadDemo extends Thread {
private Thread t;
private String threadName;
PrintDemo PD;
ThreadDemo( String name, PrintDemo pd){
threadName = name;
PD = pd;
}
public void run() {
synchronized(PD) {
PD.printCount();
}
System.out.println("Thread " + threadName + " exiting.");
}
public void start ()
{
System.out.println("Starting " + threadName );
if (t == null)
{
t = new Thread (this, threadName);
t.start ();
}
}
}
public class TestThread {
public static void main(String args[]) {
PrintDemo PD = new PrintDemo();
ThreadDemo T1 = new ThreadDemo( "Thread - 1 ", PD );
ThreadDemo T2 = new ThreadDemo( "Thread - 2 ", PD );
T1.start();
T2.start();
// wait for threads to end
try {
T1.join();
T2.join();
} catch( Exception e) {
System.out.println("Interrupted");
}
}
}
program 1 (ThreadTest - bytecode interpreted):
new Thread( new Runnable() {
public void run(){
ThreadTest.main(new String[0]);
}
});
program 2 (ThreadTest - AST interpreted):
final com.sun.source.tree.Tree tree = parse("ThreadTest.java");
new Thread( new AstInterpreter() {
public void run(){
interpret( tree );
}
public void interpret(com.sun.source.tree.Tree javaExpression){
//...
}
});
Does the resulting program 2 simulate the Thread's behavior of the initial program 1 correctly?
1) Currently, source=8 / target=8 scheme is accepted.
I see two options:
Option 1: JVM threads. Every time the interpreted program calls Thread.start you also call Thread.start and start another thread with another interpreter. This is simple, saves you from having to implement locks and other things, but you get less control.
Option 2: simulated threads. Similar to how multitasking is implemented on uniprocessors - using time slicing. You have to implement locks and sleeps in the interpreter, and track the simulated threads to know which threads are ready to run, which have finished, which are blocked, etc.
You can execute instructions of one thread until it blocks or some time elapses or some instruction count is reached, and then find another thread which may run now and switch to running that thread. In the context of operating systems this is called process scheduling - you may want to study this topic for inspiration.
You can't do partial evaluation sensibly using a classic interpreter that computes with actual values. You need symbolic values.
For partial evaluation, what you want is to compute the symbolic program state at each program point, and then simplify the program point based on the state known at that program point. You start your partial evaluation process by writing down what you know about the state when the program starts.
If you decorated each program point with its full symbolic state and kept them all around at once, you'd run out of memory fast. So a more practical approach is to enumerate all control flow paths through a method using a depth-first search along the control flow paths, computing symbolic state as you go. When this search backtracks, it throws away the symbolic state for the last node on the current path being explored. Now your saved state is linear in the size of the depth of the flow graph, which is often pretty shallow in a method. (When a method calls another, just extend the control flow path to include the call).
To handle runnables, you have to model the interleavings of the computations in the separate runnables. Interleaving the (enormous) state of two threads will get huge fast. The one thing that might save you here is most state computed by a thread is completely local to that thread, thus is by definition invisible to another thread, and you don't have to worry about interleaving that part of the state. So we are left with simulating interleaving of state seen by both two threads, along with simulation of the local states of each thread.
You can model this interleaving by implied but simulated parallel forks in the control flow: at each simulated step, either one thread makes one step progress, or the other (generalize to N threads). What you get is a new state for each program point for each fork; the actual state for the program point is disjunction of the states generated by this process for each state.
You can simplify the actual state disjunction by taking "disjunctions" of properties of individual properties. For instance, if you know that one thread sets x to a negative number at a particular program point, and another sets it to a positive number at that same point, you can summarize the state of x as "not zero". You'll need a pretty rich type system to model possible value characterizations, or you can live with an impoverished one that computes disjunctions of properties of a variable conservatively as "don't know anything".
This scheme assumes that memory accesses are atomic. They often aren't in real code so you sort of have to model that, too. Probably best to have the interpreter simply complain your program has a race condition if you end up with conflicting read and write operations to a memory location from two threads at the "same" step. A race condition doesn't make your program wrong, but only really clever code use races in ways that aren't broken.
If this scheme is done right, when one thread A makes a call on a synchronous method on an object already in use by another thread B, you can stop interleaving A with B until B leaves the synchronous method.
If there is never interference between threads A and B over the same abstract object, you can remove the synchronized declaration from the object declaration. I think this was your original goal
All this isn't easy to organize, and it is likely very expensive time/spacewise to run. Trying to draw up an example of all this pretty laborious, so I won't do it here.
Model checkers https://en.wikipedia.org/wiki/Model_checking do a very similar thing in terms of generating the "state space", and have similar time/space troubles. If you want to know more about how to manage state do this, I'd read the literature on this.
public class YieldDemo extends Thread{
public static void main(String[] args) {
YieldDemo y1 = new YieldDemo();
YieldDemo y2= new YieldDemo();
y1.start();
y2.start();
}
public void run() {
for(int i=0;i<=5;i++) {
if(i==3) {
Thread.yield();
} else
System.out.println(i+Thread.currentThread().toString());
}
}
}
As per the documentation of yield(), thread-1 should yield and allow thread-2 to process after 3rd loop. However, the output is not as expected. Same thread continues skipping 3rd iteration. After one thread completes the loop, other thread executes with same behaviour. Please explain.
Output:
0Thread[Thread-1,5,main]
1Thread[Thread-1,5,main]
2Thread[Thread-1,5,main]
4Thread[Thread-1,5,main]
5Thread[Thread-1,5,main]
0Thread[Thread-0,5,main]
1Thread[Thread-0,5,main]
2Thread[Thread-0,5,main]
4Thread[Thread-0,5,main]
5Thread[Thread-0,5,main]
The java.lang.Thread.yield() method causes the currently executing thread object to temporarily pause and allow other threads to execute.
NOTE : That other thread can be same thread again. There is no guarantee which thread be chosen by JVM.
As with almost all aspects of Multithreading, even your case isn't guaranteed to behave as expected. Thread.yield() is just like a suggestion to the OS telling - if it is possible, then please execute other threads before this one. Depending on the architecture of your system (number of cores, and other aspects like affinity etc etc) the OS might just ignore your request.
Also, after JDK6U23, the JVM might just change your code to :
public void run() {
for(int i=0;i<=5;i++) {
// 3 is too darn small. and yield() is not necessary
// so let me just iterate 6 times now to improve performance.
System.out.println(i+Thread.currentThread().toString());
}
yield() can totally be ignored (which might be happening in your case. If you are getting the same result over and over again)
Read This article. yield method is to request for a thread to sleep. it may be happen or not.
I have a loop that doing this:
WorkTask wt = new WorkTask();
wt.count = count;
Thread a = new Thread(wt);
a.start();
When the workTask is run, the count will wt++ ,
but the WorkTask doesn't seems change the count number, and between the thread, the variable can't share within two thread, what did I wrote wrong? Thanks.
Without seeing the code for WorkThread it's hard to pin down the problem, but most likely you are missing synchronization between the two threads.
Whenever you start a thread, there are no guarantees on whether the original thread or the newly created thread runs first, or how they are scheduled. The JVM/operating system could choose to run the original thread to completion and then start running the newly created thread, run the newly created thread to completion and then switch back to the original thread, or anything in between.
In order to control how the threads run, you have to synchronize them explicitly. There are several ways to control the interaction between threads - certainly too much to describe in a single answer. I would recommend the concurrency trail of the Java tutorials for a broad overview, but in your specific case the synchronization mechanisms to get you started will probably be Thread.join and the synchronized keyword (one specific use of this keyword is described in the Java tutorials).
Make the count variable static (it looks like each thread has its own version of the variable right now) and use a mutex to make it thread safe (ie use the synchronized instruction)
From your description I came up with the following to demonstrate what I perceived as your issue. This code, should output 42. But it outputs 41.
public class Test {
static class WorkTask implements Runnable {
static int count;
#Override
public void run() {
count++;
}
}
public static void main(String... args) throws Exception {
WorkTask wt = new WorkTask();
wt.count = 41;
Thread a = new Thread(wt);
a.start();
System.out.println(wt.count);
}
}
The problem is due to the print statement running before thread had a chance to start.
To cause the current thread ( the thread that is going to read variable count ) to wait until the thread finishes, add the following after starting thre thread.
a.join();
If you are wishing to get a result back from a thread, I would recommend you to use Callable
interface and an ExecutorSercive to submit it. e.g:
Future future = Executors.newCachedThreadPool().submit
(new Callable<Interger>()
{
int count = 1000;
#Override public Integer call() throws Exception
{
//here goes the operations you want to be executed concurrently.
return count + 1; //Or whatever the result is.
}
}
//Here goes the operations you need before the other thread is done.
System.out.println(future.get()); //Here you will retrieve the result from
//the other thread. if the result is not ready yet, the main thread
//(current thread) will wait for it to finish.
this way you don't have to deal with the synchronization problems and etc.
you can see further about this in Java documentations:
http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/package-summary.html
I want to write a command line daemon that runs forever. I understand that if I want the JVM to be able to shutdown gracefully in linux, one needs to wrap the bootstrap via some C code. I think I'll be ok with a shutdown hook for now.
On to my questions:
My main(String[]) block will fire off a separate Superdaemon.
The Superdaemon will poll and loop forever.
So normally I would do:
class Superdaemon extends Thread { ... }
class Bootstrap
{
public static void main( String[] args )
{
Thread t = new Superdaemon();
t.start();
t.join();
}
}
Now I figured that if I started Superdaemon via an Executor, I can do
Future<?> f = exec.submit( new Superdaemon() );
f.get();
Is Future.get() implemented with Thread.join() ?
If not, does it behave equivalently ?
Regards,
ashitaka
Yes, the way you've written these is equivalent.
However, you don't really need to wait for the Superdaemon thread to complete. When the main thread finishes executing main(), that thread exits, but the JVM will not. The JVM will keep running until the last non-daemon thread exits its run method.
For example,
public class KeepRunning {
public static void main(String[] args) {
Superdaemon d = new Superdaemon();
d.start();
System.out.println(Thread.currentThread().getName() + ": leaving main()");
}
}
class Superdaemon extends Thread {
public void run() {
System.out.println(Thread.currentThread().getName() + ": starting");
try { Thread.sleep(2000); } catch(InterruptedException e) {}
System.out.println(Thread.currentThread().getName() + ": completing");
}
}
You'll see the output:
main: leaving main()
Thread-0: starting
Thread-0: completing
In other words, the main thread finishes first, then the secondary thread completes and the JVM exits.
The issue is that books like JCIP is advocating that we use Executors to starts Threads. So I'm trying my best not to use Thread.start(). I'm not sure if I would necessarily choose a particular way of doing things just based on simplicity. There must be a more convincing reason, no ?
The convincing reason to use java.util.concurrent is that multi-threaded programming is very tricky. Java offers the tools to that (Threads, the synchronized and volatile keywords), but that does not mean that you can safely use them directly without shooting yourself in the foot: Either too much synchronization, resulting in unnecessary bottlenecks and deadlocks, or too less, resulting in erratic behaviour due to race conditions).
With java.util.concurrent you get a set of utilities (written by experts) for the most common usage patterns, that you can just use without worrying that you got the low-level stuff right.
In your particular case, though, I do not quite see why you need a separate Thread at all, you might as well use the main one:
public static void main( String[] args )
{
Runnable t = new Superdaemon();
t.run();
}
Executors are meant for tasks that you want to run in the background (when you have multiple parallel tasks or when your current thread can continue to do something else).
Future.get() will get the future response from an asynchronous call. This will also block if the call has not been completed yet. It is much like a thread join.
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Future.html
Sort'a. Future.get() is for having a thread go off and calculate something and then return it to the calling thread in a safe fashion. It'd work if the get never returned. But, I'd stick with the join call as it's simpler and no Executer overhead (not that there would be all that much).
Edit
It looks like ExecutorService.submit(Runnable) is intended to do exectly what you're attempting. It just returns null when the Runnable completes. Interesting.
Why would the compiler print 2 a and then 2 b or vice versa when giving the priority to Thread a to start? Shouldn't thread b wait for thread a to finish in order to start? Can someone please explain how does it work?
public class Test1 extends Thread{
static int x = 0;
String name;
Test1(String n) {
name = n;
}
public void increment() {
x = x+1;
System.out.println(x + " " + name);
}
public void run() {
this.increment();
}
}
public class Main {
public static void main(String args[]) {
Test1 a = new Test1("a");
Test1 b = new Test1("b");
a.setPriority(3);
b.setPriority(2);
a.start();
b.start();
}
}
Giving priorities is not a job for the compiler. It is the OS scheduler to schedule and give CPU time (called quantum) to threads.
The scheduler further tries to run as much threads at once as possible, based on the available number of CPUs. In today's multicore systems, more often than not more than one core are available.
If you want for a thread to wait for another one, use some synchronizing mechanism.
Shouldn't thread b wait for thread a to finish in order to start?
No. The priority does not block the thread execution. It only tells the JVM to execute the thread "in preference to threads with lower priority". This does imply a wait.
Since your code is so trivial, there is nothing to wait for. Any of the two threads is run.
Why would the compiler print 2 a and then 2 b?
Luck of the draw. "Priority" means different things on different operating systems, but in general, it's always part of how the OS decides which thread gets to run and which one must wait when there's not enough CPUs available to run them both at the same time. If you computer has two or more idle CPUs when you start that program, then everybody gets to run. Priority doesn't matter in that case, and its just a race to see which one gets to the println(...) call first.
The a thread in your example has an advantage because the program doesn't call b.start() until after the a.start() method returns, but how big that advantage actually is depends on the details of the OS thread scheduling algorithm. The a thread could get a huge head start (like, it actually finishes before b even starts), or it could be a near-trivial head start.