| Author |
volatile keyword
|
Ram Manoj
Ranch Hand
Joined: Jan 12, 2008
Posts: 52
|
|
|
Can anyone the practical usage of 'volatile' keyword comparing it with 'synchronized' keyword with an example?
|
 |
Paul Michael
Ranch Hand
Joined: Jul 02, 2001
Posts: 697
|
|
Volatile variables share the visibility features of synchronized, but none of the atomicity features. This means that threads will automatically see the most up-to-date value for volatile variables. They can be used to provide thread safety, but only in a very restricted set of cases: those that do not impose constraints between multiple variables or between a variable's current value and its future values. So volatile alone is not strong enough to implement a counter, a mutex, or any class that has invariants that relate multiple variables (such as "start <=end"). You might prefer to use volatile variables instead of locks for one of two principal reasons: simplicity or scalability. Some idioms are easier to code and read when they use volatile variables instead of locks. In addition, volatile variables (unlike locks) cannot cause a thread to block, so they are less likely to cause scalability problems. In situations where reads greatly outnumber writes, volatile variables may also provide a performance advantage over locking.
Source: Java theory and practice: Managing volatility There's also an interesting book called Java Concurrency in Practice which you might want to checkout.
|
SCJP 1.2 (89%), SCWCD 1.3 (94%), IBM 486 (90%), SCJA Beta (96%), SCEA (91% / 77%), SCEA 5 P1 (77%), SCBCD 5 (85%)
|
 |
Ram Manoj
Ranch Hand
Joined: Jan 12, 2008
Posts: 52
|
|
Thankyou Paul, The links are valuable source of information regarding 'volatile' keyword and it usage. Even after going through the article on "Managing volatility", the volatile is still a fuzzy picture for me. Much of it is due to
Conditions for correct use of volatile You can use volatile variables instead of locks only under a restricted set of circumstances. Both of the following criteria must be met for volatile variables to provide the desired thread-safety: Writes to the variable do not depend on its current value. The variable does not participate in invariants with other variables.
How come a write to a volatile variable's value be not dependent on its current value? Probably I have to delve deep/analyze the article once more or have to write a useful program to understand. More info on this is welcome.
|
 |
Jelle Klap
Bartender
Joined: Mar 10, 2008
Posts: 1409
|
|
Originally posted by Ram Manoj: How come a write to a volatile variable's value be not dependent on its current value?
From the same article:
The first condition disqualifies volatile variables from being used as thread-safe counters. While the increment operation (x++) may look like a single operation, it is really a compound read-modify-write sequence of operations that must execute atomically -- and volatile does not provide the necessary atomicity. Correct operation would require that the value of x stay unchanged for the duration of the operation, which cannot be achieved using volatile variables.
And the book Paul Michael suggested, Java Concurrency in Practice, is truely excellent. I also highly recommend it.
|
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
|
 |
 |
|
|
subject: volatile keyword
|
|
|