Difference results for the same program

Question

public class suspendCheck extends Thread{

    int t ;

    public static void main(String args[]) throws InterruptedException {
        suspendCheck as = new suspendCheck();

        Thread t2 = new Thread(as);
        t2.start();
        Thread t3 = new Thread(as);
        t3.start(); }

    public void run(){
        if(t==0){
        System.out.println("JAVA Develper");
        t= ++t;
        }
        else{

            System.out.println("JAVA Test");
            }

        }
}

After running this program multiple times there are differences and discrepancies:

Usually:

JAVA Develper
JAVA Develper

And occasionally:

JAVA Develper
JAVA Test

I am horrified by this. Where did I go wrong?

Yes, it is acceptable. The only horrifying thing here is that you attempt to use thread without knowing their limitations. Blaming Java isn't the right thing to do here. — nanofarad, Sep 01 '13 at 08:22
I just don't understand why people gave -1 for this question, he just has no experience in multithreading — anvarik, Sep 01 '13 at 09:13

score 7 · Answer 1 · edited May 23 '17 at 10:26

7

Yes, it is acceptable. The only horrifying thing here is that you attempt to use thread without knowing their limitations.

You could easily do this with one thread. You could take the safe path here.

Threads do not guarantee anything regarding optimizations and ordering. If you really want your int to change properly, make it volatile and/or use an AtomicInteger. If you want even better control use locks and/or synchronized blocks.

In this case, just declare t as volatile and synchronize around accesses to t or AtomicInteger and use that class's methods to access t.

For future reference, trying things like these without reading all associated warnings can lead to death, asphyxiation, chills, fever, drowing, infection, nausea, and the inability to control highly expensive machinery.

edited May 23 '17 at 10:26

Community

1
1

answered Sep 01 '13 at 08:21

nanofarad

40,330
4
86
117

2

++t is not atomic, so volatile not enough here (assuming the OP wants the first println to be only printed once). And with AtomicInteger he will need a CAS and avoid the check-then-act that he is currently using... – assylias Sep 01 '13 at 08:24
+1 If you want a specific order, use one thread. It will be simpler and if often faster as well. – Peter Lawrey Sep 01 '13 at 08:24
4

@assylias t = ++t is even more confused ;) – Peter Lawrey Sep 01 '13 at 08:25
@PeterLawrey I had not even noticed! – assylias Sep 01 '13 at 08:26
1

Just as a heads-up, that link at the end is a nice read for a thread horror story. – nanofarad Sep 01 '13 at 08:27

No Idea For Name · Answer 2 · 2013-09-01T08:42:05.463

1

i just want to add to hexafraction answer that you should read on race condition:

here
here

and to explain that what you did in your code is to make several threads to try to take an integer and change it in a way that one of them may change it while the other thread is taking it and thus override a value given by the first thread. that's why you're getting this behavior

Race condition in Java is a type of concurrency bug or issue which is introduced in your program because parallel execution of your program by multiple threads at same time, Since Java is a multi-threaded programming language hence risk of Race condition is higher in Java which demands clear understanding of what causes a race condition and how to avoid that.

edited Sep 01 '13 at 08:42

answered Sep 01 '13 at 08:28

No Idea For Name

11,411
10
42
70

Links to external sites without summaries are discouraged. I encourage you to add a summary of how race conditions occur in general. – nanofarad Sep 01 '13 at 08:32
@hexafraction will do, just gimme a minute – No Idea For Name Sep 01 '13 at 08:41
OK, no problem. I'm just offering a piece of advice. – nanofarad Sep 01 '13 at 08:42

score 0 · Answer 3 · answered Sep 01 '13 at 08:49

You cannot guarantee the order of execution of threads.When you call start() method on a thread, it is now upto the thread scheduler to what should be the order of execution

t1.start();
t2.start();

This doesn't imply t1 will definitely run before t2. In your example, you are not synchronizing the method,both the threads may be running simultaneously,or by the time one thread comes to line 4, the other may have already finished executing.

 public void run(){
        if(t==0){
        System.out.println("JAVA Develper");
        t= ++t;    //Line 4
        }
        else{

            System.out.println("JAVA Test");
            }

        }

Synchronized methods will provide the thread a lock on an object.No other thread having the same object as runnable ,will be able to access the synchronized block or a method simultaneously .

 synchronized public void run()

score 0 · Answer 4 · answered Sep 01 '13 at 08:56

you should use threads if stuff needs to happen in parallel, in stead of serial. Unless you explicitly synchronise, which kind of breaks the idea of threads, things will happen in an undefined order.

Understanding threading and getting it absolutely right is both critical and the single most difficult thing to do in just about any language.

I'd recommend reading java concurrency in practice by joshua bloch to see just how many pittfalls there are when using threads and, more importantly, sharing state.

Java concurrency in practice is by Brian Goetz (Joshua Bloch was a contributing author) — Mark Rotteveel, Sep 01 '13 at 08:58

Difference results for the same program

4 Answers4