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

On Tue, 28 Apr 2020 at 13:00, Ludwig, Mark via Concurrency-interest
<[email protected]> wrote:
>
> Thank you.  My most-paranoid architect doesn't consider that language a
>
> sufficient guarantee, so we’re going with another pattern I started using about
>
> 15 years ago, after I got my head around the final field semantics in Java
>
> [1.]5, for lock-free "steady state" access elsewhere in our product.
>
>
>
> I am interested in a little review of this pattern by JLS & JMM experts here.

Hi Mark

I agree with Tim you are wasting your time with this. I can't think of any sane
implementation where you would run into any issue.
The chance of you introducing a bug with a homegrown solution is a lot bigger
than this ever being a problem.

But if you really believe that there might be an issue with memory effects just
declare:

class ShowDataAccess
  volatile field FilterConfig;

and you should be safe.

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.

/Kasper

[1] https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest