This week's book giveaway is in the Agile and other Processes forum. We're giving away four copies of The Mikado Method and have Ola Ellnestam and Daniel Brolund on-line! See this thread for details.
As described in �17, the Java programming language allows threads that access shared variables to keep private working copies of the variables; this allows a more efficient implementation of multiple threads. These working copies need be reconciled with the master copies in the shared main memory only at prescribed synchronization points, namely when objects are locked or unlocked. As a rule, to ensure that shared variables are consistently and reliably updated, a thread should ensure that it has exclusive use of such variables by obtaining a lock that, conventionally, enforces mutual exclusion for those shared variables. The Java programming language provides a second mechanism, volatile fields, that is more convenient for some purposes. A field may be declared volatile, in which case a thread must reconcile its working copy of the field with the master copy every time it accesses the variable. Moreover, operations on the master copies of one or more volatile variables on behalf of a thread are performed by the main memory in exactly the order that the thread requested.
There's more information there if this isn't enough for you, but I thought this was a pretty good explanation. I hope that helps, Corey
thanks Corey ! but I am still confussed at the ex of JLS explanation: class Test { static volatile int i = 0, j = 0; static void one() { i++; j++; } static void two() { System.out.println("i=" + i + " j=" + j); } } This allows method one and method two to be executed concurrently, but guarantees that accesses to the shared values for i and j occur exactly as many times, and in exactly the same order, as they appear to occur during execution of the program text by each thread. Therefore, the shared value for j is never greater than that for i, because each update to i must be reflected in the shared value for i before the update to j occurs. It is possible, however, that any given invocation of method two might observe a value for j that is much greater than the value observed for i, because method one might be executed many times between the moment when method two fetches the value of i and the moment when method two fetches the value of j. the j still can much greater than i, so what is the usage of volatile? thanks Krussi
Corey McGlone
Ranch Hand
Joined: Dec 20, 2001
Posts: 3271
posted
0
Think about it this way. In order to increase performance, the JVM allows threads to "cache" values of member variables. However, if multiple threads might be sharing this member variable, you could run into data integrity problems. But, if you make the member volatile, then, each time any thread tries to access that member, it is forced to read the true value, rather than using a "cached" value. I hope that helps, Corey
krussi rong
Ranch Hand
Joined: Jan 30, 2002
Posts: 62
posted
0
thanks Corey very much! krussi
I agree. Here's the link: http://ej-technologies/jprofiler - if it wasn't for jprofiler, we would need to
run our stuff on 16 servers instead of 3.
0
