About Question enthuware.ocpjp.v8.2.1558 :
Moderator: admin
-
- Posts: 1
- Joined: Sat Apr 30, 2016 4:10 am
- Contact:
About Question enthuware.ocpjp.v8.2.1558 :
Hello!
The variable "threadcounter" is static, then your value is only one. The final instruction of explanations is wrong:
"It is, therefore, possible that each of the ten threads see its value as 0 and updated it to 1. Thus, one possible outcome could be that 1 is printed 10 times!"
When of all threads executes the method run, even if the same time, the variable "threadcounter" will be increased. Right or not?
The variable "threadcounter" is static, then your value is only one. The final instruction of explanations is wrong:
"It is, therefore, possible that each of the ten threads see its value as 0 and updated it to 1. Thus, one possible outcome could be that 1 is printed 10 times!"
When of all threads executes the method run, even if the same time, the variable "threadcounter" will be increased. Right or not?
-
- Site Admin
- Posts: 10064
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1558 :
No, the explanation is correct. As explained in the explanation, threadcounter is not volatile and none of the threads are accessing the variable in a synchronized block, so one thread may change its value from 0 to 1 but another thread may still see 0.
If you like our products and services, please help us by posting your review here.
-
- Posts: 15
- Joined: Wed May 10, 2017 2:49 am
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1558 :
Hi,
Is there any possibility to get the final value of the variable threadCounter greater than 10?
Is there any possibility to get the final value of the variable threadCounter greater than 10?
-
- Site Admin
- Posts: 10064
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1558 :
No, that is not possible.
If you like our products and services, please help us by posting your review here.
-
- Posts: 15
- Joined: Wed May 10, 2017 2:49 am
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1558 :
Hi,
Thanks for the reply. Im confused with the statement about volatile and atomic. Let say the increment operation for threadCounter is atomic but the variable is not declared volatile. In such scenario, can we say that the final value of threadCounter will be always 10?
Regards,
Shamran
Thanks for the reply. Im confused with the statement about volatile and atomic. Let say the increment operation for threadCounter is atomic but the variable is not declared volatile. In such scenario, can we say that the final value of threadCounter will be always 10?
Regards,
Shamran
-
- Site Admin
- Posts: 10064
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1558 :
First, you need to realize that Java does not have any atomic increment operator. What Java has is an AtomicInteger class, which supports methods to increment/decrement the value inside an object of this class atomically.
Second, you need to realize that int i and AtomicInteger ai are two entirely different kind of things. int is a primitive while AtomicInteger is a class. So when you do i++, you are changing the value of the variable i. To make this new value visible to other threads, you need to make i volatile. This part has nothing to do with atomicity.
When you call ai.incrementAndGet(), you don't change the value of ai. ai still keeps pointing to the same AtomicInteger object as before. This is the fundamental difference between a primitive and a reference. So there is no need for ai to be declared volatile here because ai doesn't change. The integer value that is kept inside the AtomicInteger object is incremented and it is incremented atomically so every threads gets to see the incremented value of its integer value correctly and no updates are lost.
HTH,
Paul.
Second, you need to realize that int i and AtomicInteger ai are two entirely different kind of things. int is a primitive while AtomicInteger is a class. So when you do i++, you are changing the value of the variable i. To make this new value visible to other threads, you need to make i volatile. This part has nothing to do with atomicity.
When you call ai.incrementAndGet(), you don't change the value of ai. ai still keeps pointing to the same AtomicInteger object as before. This is the fundamental difference between a primitive and a reference. So there is no need for ai to be declared volatile here because ai doesn't change. The integer value that is kept inside the AtomicInteger object is incremented and it is incremented atomically so every threads gets to see the incremented value of its integer value correctly and no updates are lost.
HTH,
Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 85
- Joined: Mon Dec 24, 2018 6:24 pm
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1558 :
Hi, I am kinda surprise that no one ask how main method access this synchronized block. It first checks whether main thread is TestClass or not. Basically, each loop same main thread will enter the synchronized block and create a new Thread; therefore, it prints 10 numbers but which number will be printed and the order of these 10 number can not be determined. I hope my logic is correct. Please verify, thanks.
-
- Site Admin
- Posts: 10064
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1558 :
Yes, you got it right.
The main thread acquires the lock of TestClass.class object in every iteration. (A thread is allowed to reacquire the same lock any number of times.) In each iteration, it creates and starts a new thread.
The main thread acquires the lock of TestClass.class object in every iteration. (A thread is allowed to reacquire the same lock any number of times.) In each iteration, it creates and starts a new thread.
If you like our products and services, please help us by posting your review here.
-
- Posts: 19
- Joined: Fri Aug 02, 2019 7:04 am
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1558 :
I am a bit confused about the role of synchronized block over here. What i have understood is, the main thread acquires the lock on TestClass.class, spawns a new thread from within it and exits the block. It does not wait for the spawned thread to complete. If that would have been the case, the results would have been ordered and it would defy the multi-threading concept in this context. Please verify if my understating is correct, thanks.
-
- Site Admin
- Posts: 10064
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1558 :
Correct.
If you like our products and services, please help us by posting your review here.
Who is online
Users browsing this forum: No registered users and 106 guests