Shaddy Khan wrote:
please help me to figure out why vloatile is not working
Steve
Steve Luke wrote:If you want/need atomic actions like those in the code above you should use AtomicInteger, or if you have a large amount of competition for setting the value, or complex data to protect. you should use synchronization (Locks or synchronized blocks). But you can not use volatile in this case.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:I'm pretty sure (and I'm sure Steve et al will let me know if I'm wrong ) that once a variable (other than an array) is volatile, the only thing that needs to be synchronized is the action that writes to it.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Shaddy Khan wrote:
@ Richard: i expect the value of count would be 2000 each time i runs the program.
As per my code i m trying to increment the value of count to 2000 via two threads with help of volatile.
Ref# http://docs.oracle.com/javase/tutorial/essential/concurrency/atomic.html
Shaddy Khan wrote:@Richard: i already made the count as volatile. As this code is testing of volatile only otherwise i can fix this case with the help of AtomicInteger or synchronization as mentioned in the my first post.
Richard Tookey wrote:Using
one solves the problem but one still needs to make count 'volatile' because otherwise the JVM is at liberty to only update the value of 'count' when the increment() method exits.
17.4.3. Programs and Program Order
Among all the inter-thread actions performed by each thread t, the program order of t is a total order that reflects the order in which these actions would be performed according to the intra-thread semantics of t.
A set of actions is sequentially consistent if all actions occur in a total order (the execution order) that is consistent with program order, and furthermore, each read d of a variable v sees the value written by the write w to v such that:
* w comes before d in the execution order, and
* there is no other write w' such that w comes before w' and w' comes before d in the execution order.
17.4.4. Synchronization Order
Synchronization actions induce the synchronized-with relation on actions, defined as follows:
* An unlock action on monitor m synchronizes-with all subsequent lock actions on m
17.4.5. Happens-before Order
Two actions can be ordered by a happens-before relationship. If one action happens-before another, then the first is visible to and ordered before the second.
If we have two actions x and y, we write hb(x, y) to indicate that x happens-before y.
* If x and y are actions of the same thread and x comes before y in program order, then hb(x, y).
* If an action x synchronizes-with a following action y, then we also have hb(x, y).
* If hb(x, y) and hb(y, z), then hb(x, z).
A set of synchronization edges, S, is sufficient if it is the minimal set such that the transitive closure of S with the program order determines all of the happens-before edges in the execution. This set is unique.
It follows from the above definitions that:
* An unlock on a monitor happens-before every subsequent lock on that monitor.
* All actions in a thread happen-before any other thread successfully returns from a join() on that thread.
Steve
Richard Tookey wrote:
Shaddy Khan wrote:@Richard: i already made the count as volatile. As this code is testing of volatile only otherwise i can fix this case with the help of AtomicInteger or synchronization as mentioned in the my first post.
You seem to have missed my point but never mind. Probably my bad English.
Steve
Who among you feels worthy enough to be my best friend? Test 1 is to read this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|