river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: QA Test debugging
Date Tue, 26 Feb 2013 12:30:24 GMT
On 26 February 2013 12:20, Dan Creswell <dan.creswell@gmail.com> wrote:
> On 26 February 2013 12:08, Patricia Shanahan <pats@acm.org> wrote:
>> On 2/26/2013 3:05 AM, Dan Creswell wrote:
>> ...
>>
>>> Final of course meaning nothing other than "value won't change" - a
>>> compile/language level guarantee.
>>>
>>> It doesn't interact in any meaningful way with the JVM concurrency
>>> mechanics. i.e. it doesn't have any relationship to a synchronization
>>> action (or barrier as I prefer). Thus final provides no multi-thread
>>> guarantee explicitly. What one can say is that once the value becomes
>>> visible to a set of threads it won't change.
>>
>> ...
>>
>> How do you view the following JLS section 17.5 Final Field Semantics?
>> http://docs.oracle.com/javase/specs/jls/se5.0/html/memory.html#66562
>>
>> In particular, that section says "An object is considered to be completely
>> initialized when its constructor finishes. A thread that can only see a
>> reference to an object after that object has been completely initialized is
>> guaranteed to see the correctly initialized values for that object's final
>> fields."
>
> I think the key phrase is "a thread that can only see a reference to an object".
>
> If you were the thread that did the creation, you have a reference and
> final's must be initialised by end of construction thus you are
> guaranteed to see the correct values.
>
> If you were another thread, the only way you could get that object
> reference is via some synchronisation barrier/action (which flushes
> any values sitting in a core cache and makes them visible to all
> processor cores). At this point you have a valid object reference and
> all the initialisation done in the constructor has also been made
> visible to you by the flush. This, to me, is the implicit unwritten
> element of the above specification.
>
> Final just means "at end of construction this field will be
> initialised and not change".
>

Or put another way: final is a guarantee of when initialisation will
have been completed from the point of view of the caller of new and
the implementer of the class. It says nothing about the memory/core
visibility of that initialisation.


>
>>
>> Patricia
>>
>>

Mime
View raw message