Re: Guarantees around Servlet Filter initialization that sets an instance variable?

Thank you.  I have a follow-up question....

> From: Kasper Nielsen <[email protected]>, Tuesday, April 28, 2020 9:21 AM
> 
> The code you posted it basically good old double-checked-locking [1] in
> disguise. There is no happens-before relationship between
> SynchronizedDataAccessor.setAll and subsequent calls to
> UnsynchronizedDataAccessor.getConfig. So you have accomplished nothing.
> Other
> than confusing your co-workers.

I think you're saying I misunderstand this language (from
https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5):

------------------------------------------------------------
final fields also allow programmers to implement thread-safe
immutable objects without synchronization. A thread-safe
immutable object is seen as immutable by all threads, even
if a data race is used to pass references to the immutable
object between threads. This can provide safety guarantees
against misuse of an immutable class by incorrect or
malicious code. final fields must be used correctly to
provide a guarantee of immutability.

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.

The usage model for final fields is a simple one: Set the
final fields for an object in that object's constructor; and
do not write a reference to the object being constructed in
a place where another thread can see it before the object's
constructor is finished. If this is followed, then when the
object is seen by another thread, that thread will always
see the correctly constructed version of that object's final
fields. It will also see versions of any object or array
referenced by those final fields that are at least as
up-to-date as the final fields are.
------------------------------------------------------------

At the end of the reference you sent, the following 
seems to support what I'm trying to do:
------------------------------------------------------------
Double-Checked Locking Immutable Objects

If Helper is an immutable object, such that all of the
fields of Helper are final, then double-checked locking will
work without having to use volatile fields. The idea is that
a reference to an immutable object (such as a String or an
Integer) should behave in much the same way as an int or
float; reading and writing references to immutable objects
are atomic.
------------------------------------------------------------

Is the following statement not effectively atomic -- can the
'data' reference point to the not-completely-initialized
UnsynchronizedDataAccessor object?

         data = new UnsynchronizedDataAccessor(config);

I thought the effectively-atomic behavior derives from an
update of a reference always being atomic; the rest from
construction of an object with only final fields being
effectively atomic, which I thought was guaranteed by the
statements in the JLS I referenced above, because the
constructed UnsynchronizedDataAccessor object only has final
fields.

I appreciate being educated/disabused....

Thanks!
Mark
_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest