Getting away from safety guarantees for the moment.
When you do a lock, you need to flush all cached values from registers.
Does this apply to final fields? As I read the old memory model, I
suspect it does. However, I expect that most implementations do not
flush final fields.
Could this ever matter? Yes. Say in thread T1 a constructor publishes
a reference to a partially constructed object, before writing to a
final field of the object being constructed. Another thread T2 grabs
the reference, reads the field, tries to obtain a lock. But T1
already holds the lock, so T2 suspends. T1 resumes, initializes the
field, and then releases the lock. T2 resumes, doing a memory barrier
and then re-reading the final field.
If a lock flushes final fields, then T2 would need to see the new
value for the field. If locks aren't required to flush fields, then
T2 could reuse the value it had loaded earlier (which would be the
default value).
What do you think? The only situations where this could be observed
are painfully bad code.
Note that this doesn't conflict with the other ideas we suggested
about final or final volatile fields never being stale. What we could
say is something like:
* When a thread reads a final (or perhaps a volatile final) field,
then value it reads must reflect all writes to that field at the time
the object was published; Furthermore, it is legal for a thread to
reuse the value of a final field, even if memory barriers intervene.
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