At 3:37 PM -0400 7/24/99, Doug Lea wrote:
>Sorry to be so dense about this, and to keep asking/commenting about
>variations on it, but are there any interesting cases where
>programmers would NOT replace current `final' declarations with
>`volatile final'? In which case, why introduce it?
>
If we made final be different than "volatile final", then on some
architectures (e.g., DEC Alpha) referencing a final variable would be
more efficient than accessing a final volatile variable (a memory
barrier would be required on the Alpha to access a final volatile
variable).
Here is one way to think of it: _not_ declaring a variable as
volatile is only a performance hack. Take any program, mark all of
the fields as volatile, and it should still work (although perhaps
more slowly). Perhaps it is better to think of volatile as being the
"natural state" of a field, and marking it nonvolatile indicates that
you aren't going to have data races on it and allows the system to do
some optimizations on it.
For example, if you had a final private variable, and all of the
methods of the class were synchronized, then you could be guaranteed
that you don't have a data race on it and you could mark safely the
variable as non-volatile.
Feel free to rephrase the question again if my response isn't clear.
Bill
-------------------------------
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email majordomo@cs.umd.edu and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:17 EDT