Forums Register Login

Thread

+Pie Number of slices to send: Send
www.javabaet.com




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.
+Pie Number of slices to send: Send
+Pie Number of slices to send: Send
Output always will be 0246.

Using boolean parameter, the code ensures that run method will be executed before getResult completes.
+Pie Number of slices to send: Send
 

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??
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
while(!iscom)

Hey it is checking ! of iscom. So it will be true.
+Pie Number of slices to send: Send
I am sorry i did not notice it, but still wait will be called and thread will be waiting until notify is called.
+Pie Number of slices to send: Send
What i was trying to find is.....
I know 0246 is a possible result.
Isn't 2064 a possible result???
+Pie Number of slices to send: Send
 

Isn't 2064 a possible result???



NO. order will be always same that is 0246
+Pie Number of slices to send: Send
 

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


Why?
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
using this :


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 :


I hope this makes sense.
+Pie Number of slices to send: Send
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...
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

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


I hope this makes sense.



Your given snippet will hold the main thread forever.
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

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.





+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

No. See my revisions.



You mean my complete explanation is wrong?? or what i said about synchronization is wrong??.
+Pie Number of slices to send: Send
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.
I don't like that guy. The tiny ad agrees with me.
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 1377 times.
Similar Threads
Print Odd and even number in sequence with using two threads
wait and notify
Worker thread. Comments please
syncronization confusion!!
static synchronization
More...

All times above are in ranch (not your local) time.
The current ranch time is
Apr 16, 2024 02:41:57.