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

> From: Kasper Nielsen <[email protected]>, Tuesday, April 28, 2020 11:03 AM
> 
> 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

Hi Kasper,

Thank you.  Sorry, but in my attempt to present a simple
example, I unintentionally misled by using FilterConfig as
the thing that's being stored and retrieved.  In fact, some
int and boolean values are calculated from the contents of
the FilterConfig, and they are stored and retrieved.  I
didn't want to add yet another object into the example, but
I should have....

I know this is theoretical.  This is a very simple example,
compared to the data actually involved in this pattern.  I
agree that it's overkill, that none of this is necessary,
but faced with an insistent architect, I have a very real
risk with scalability on my customers' big, non-Intel
machines (Solaris on SPARC, AIX on POWER, and HP-UX on
Itanium, to be precise).  Maybe using volatile is okay, but
can anyone tell me how the barrier it imposes will scale on
all these different architectures?

I am only trying to get a "read" on this approach, somewhat
generally -- really, whether there are restrictions on
reordering to prevent the traditional problem with
double-checked locking.

Since you only expressed concerned about something that's
(unfortunately) irrelevant (sorry, again), I believe I have
my answer.  Anyway, I realized there is the statement that
init() completes before any doFilter() calls, so /that/
ensures that the constructor has completed and the object is
fully initialized, before it's possible for doFilter() to
pick up the reference.  It might not be the precise
definition of happens-before that you'd like to see, but
it's good enough for me.

Thanks again,
Mark

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