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

Hi Mark,

This is all getting theoretical, as you are unlikely to experience
this in practice.
But you don't know how FilterConfig is implemented. Your logic relies on the
fact the FilterConfig itself can be used racely. Maybe it has non-final fields.
You just don't know.

/Kasper

On Tue, 28 Apr 2020 at 16:33, Ludwig, Mark <[email protected]> wrote:
>
> 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