[concurrency-interest] dealing with people that questionvisibility problems
joe.bowbeer at gmail.com
Thu Feb 22 00:52:03 EST 2007
A question and a comment.
Q: Can we agree on whether "setter-injected fields of
container-managed beans" (in Spring?) do or do not need additional
synchronization? I remember analyzing this before and delving through
the Spring sources and I thought I'd decided that no additional
synchronization was needed. I'd like us to agree on this before
deciding on a remedy.
C: As for volatile, if I were a professor I would be very tempted to
subtract points for their use. (Remember the days when goto existed
but no one was allowed to use it?) Even though there are a few very
good uses for volatiles (and gotos as well), they can always be
avoided and I think concurrent programming in Java is best learned
without them, as least initially.
While David's concerns are about the performance of extraneous
volatiles, my concerns are almost entirely about readability and
maintainability. Undocumented volatiles are a big stumbling block
when I'm trying to understand someone else's code. That one keyword
can mean all sorts of things. Extraneous volatiles are very hard to
remove with confidence, and make the code unnecessarily hard to
In my view, adorning code with volatile just-in-case there might be a
visibility problem is worse than doing nothing.
On 2/21/07, Tim Peierls <tim at peierls.net> wrote:
> On 2/21/07, David Holmes <dcholmes at optusnet.com.au> wrote:
> > Making all variables volatile fixes only pure-visibility bugs and in the
> process will totally kill performance by disallowing a slew of
> This is less likely to be a concern in setter-injected fields of beans
> managed by a container framework.
> > My contention is that it is more likely that there is an atomicity bug as
> well as a visibility bug, and that volatile won't help fix it.
> Again, not as likely in setter-injected fields of container-managed beans,
> where the wiring together of multiple fields is usually independent.
> I think the hard-core concurrency view in this case does a disservice to
> application programmers, who will be unduly swayed by phrases like "will
> totally kill performance by disallowing a slew of optimizations". They will
> rush to remove the volatile keyword and they will hear the Spring expert
> say, "Trust ApplicationContext -- it does the right thing," and then they
> won't bother thinking about the possibility that their bean might someday be
> deployed in a framework that doesn't provide the requisite guarantees.
> I'm not saying that it is right to blindly make every field volatile and
> claim correctness. I'm saying if you have a setter-injected field of a
> container-managed bean, it's unlikely to be significant performance problem
> to make that field volatile (or to synchronize access to that field) -- but
> the cost of failing to guard it in some way is potentially huge.
More information about the Concurrency-interest