Thread

[Kedar Nath]

www.javabaet.com

class Comp extends Thread{
    private int num,result;
    private boolean iscom;
    public Comp(int num){
        this.num=num;
       }
    public synchronized void run(){
        result = num*2;
        iscom =true;
        notify();
}
    public synchronized int getResult(){
        while(!iscom){
            try{
                wait();
            }
            catch(Exception e){}
            
        }
        return result;
    }
    
    public static void main(String... arg){
        Comp[] comp= new Comp[4];
        for(int i =0;i<comp.length;i++){
            comp[i]= new Comp(i);
            comp[i].start();
        }
        for(Comp c: comp){
            System.out.println(c.getResult()+"");
        }
    }
}

Isn't the result" 2064 " not possible .
If not why??

I think it is possible because, anyone thread can be picked by the JVM from the four threads which are in runnable state.

[Kedar Nath]

[ramesh maredu]

Output always will be 0246.

Using boolean parameter, the code ensures that run method will be executed before getResult completes.

[Kedar Nath]

ramesh maredu wrote:Output always will be 0246.

Using boolean parameter, the code ensures that run method will be executed before getResult completes.

I understand what you say.. but why the other result is not possible??

[ramesh maredu]

It can not be other order, because assume that second for loop started first, it can not complete the getResult method body because boolean property num of that particular object is still false;
for loop execution can be interrupted temporarily because other thread is executing, but order of for loop execution can not be altered so output always will be 0246.

[Kedar Nath]

while(!iscom)

Hey it is checking ! of iscom. So it will be true.

[ramesh maredu]

I am sorry i did not notice it, but still wait will be called and thread will be waiting until notify is called.

[Kedar Nath]

What i was trying to find is.....
I know 0246 is a possible result.
Isn't 2064 a possible result???

[ramesh maredu]

Isn't 2064 a possible result???

NO. order will be always same that is 0246

[James Tharakan]

ramesh maredu wrote:
NO. order will be always same that is 0246

Why?

[ramesh maredu]

If getResult method is called before the run method on an object, it will be waiting until run method is completed, if run is completed then only it will return result value.I tested with 100 and 1000 objects but the order is always same it is ascending.

[Adeel Ansari]

A few points I would like to make clear,

- All the thread operating on its own object, hence I believe synchronized is not needed
- Second the threads might calculate in arbitrary order, but the printing is happening in a particular order - in the snippet - by the main thread
- In case the result is not calculated yet, main thread will wait for that and not proceed to print further results

Thanks.

[Monu Tripathi]

using this :

for(int i =0;i<comp.length;i++){   
            comp[i]= new Comp(i);   
            comp[i].start();   
        }  

You are creating four instances of threads and starting them. JVM is free to choose any of them or continue with the main thread.
If JVM decides to continue with the main thread, it will try to print the result using the get result function. Inside the getresult() function, using the boolean you are ensuring that the run method for that thread instance has already run. So, there will be a result to print. To paraphrase, If the run method has not executed, the thread will wait for a notification. Note that synchronization is done on "this", and there would be (four) Comp() instances.

Each of these (four separate)instances have three fields a num(sequence num), result and a boolean which indicates whether the run() has executed. For every instance you create the num field is initialised as 0,1,2,3 and so the result field will be (num*2) = 0,2,4,6. This result will be computed in the run method and will be copied to appropriate fields of the instances. This can happen in any order.
You are printing the result in a sequential manner. Note that the blocking of getresult will be sequential. When getresult is blocked on say instance number 2, unless it is unblocked, the for loop will not move further to next instance. Paraphrase, there will be only one method in the wait pool at a time.

You can try this out with this :

for(int i =0;i<comp.length;i++)   
			comp[i]= new Comp(i);  

		for(Comp c: comp){   
			System.out.println(c.getResult()+"");   
		}   

		for(int i =0;i<comp.length;i++){   
//			comp[i]= new Comp(i);   
			comp[i].start();   
		}   

I hope this makes sense.

[Kedar Nath]

Thanks Monu Tripathi ,

Monu Tripathi wrote:When getresult is blocked on say instance number 2, unless it is unblocked, the for loop will not move further to next instance.

this sentence cleared my doubt.
I should have noticed that BLOCKING...

[ramesh maredu]

All the thread operating on its own object, hence I believe synchronized is not needed

Yes.

Second the threads might calculate in arbitrary order, but the printing is happening in a particular order in the snippet by the main thread

Yes. getResult is forced to wait to maintain order.

[Adeel Ansari]

Monu Tripathi wrote:
using this :
You can try this out with this :

for(int i =0;i<comp.length;i++)   
			comp[i]= new Comp(i);  

		for(Comp c: comp){   
			System.out.println(c.getResult()+"");   
		}   

		for(int i =0;i<comp.length;i++){   
//			comp[i]= new Comp(i);   
			comp[i].start();   
		}   

I hope this makes sense.

Your given snippet will hold the main thread forever.

[Adeel Ansari]

ramesh maredu wrote: Yes. getResult is forced to wait to maintain order.

Yes, because wait() is on the current executing thread, the main thread in this case. The same result can be achieved after removing synchronized.

[ramesh maredu]

Yes, but why the main thread will not move further with other threads? Lets assume the lock is held on second object, proceeding further doesn't require the same lock. Isn't it?

.

Here order is maintained not because of locks, please note that threads are created on different objects.Synchronization key word is not doing anything there.


Assume that 0,2 are printed to console(means two for loops are executed twice), now assume that to print 4 JVM called getResult method.If run method on this object is not called yet, this particular thread will be waiting to get notified.

Mean time two options are possible

first is, JVM can call another execution of second for loop, if it does so another thread(which is having num value 2) will be waiting because first for loop is not completed yet with 3 rd iteration.

Second is JVM can continue with first for loop, if it does so it will execute run method on third object so it will call notify method so that particular object will be notified and output 4 will be printed.

[Monu Tripathi]

Adeel Ansari wrote:
Your given snippet will hold the main thread forever.

Absolutely correct.

The point i was trying to make is that the result printing will be sequential since, there main thread will hang when getresult() is in wait state.

[Adeel Ansari]

ramesh maredu wrote:
Here order is maintained not because of locks, please note that threads are created on different objects.Synchronization key word is not doing anything there.

Assume that 0,2 are printed to console(means two for loops are executed twice), now assume that to print 4 JVM called getResult method.If run method on this object is not called yet, this particular thread will be waiting to get notified.

Mean time two options are possible

first is, JVM can call another execution of second for loop, if it does so another thread(which is having num value 2) will be waiting because first for loop is not completed yet with 3 rd iteration.

Second is JVM can continue with first for loop, if it does so it will execute run method on third object so it will call notify method so that particular object will be notified and output 4 will be printed.

No. See my revisions.

[ramesh maredu]

No. See my revisions.

You mean my complete explanation is wrong?? or what i said about synchronization is wrong??.

[Adeel Ansari]

Actually, your first sentence is similar to what I said earlier. So, no disagreement, indeed.

Well, your other arguments not needed IMHO, as the main thread would wait until notified, if waits. I think this is enough to make the thing clear. I am not disagreeing with the display in a sequence thing.

I hope your doubts are clear.