[concurrency-interest] dealing with people that questionvisibility problems

Tim Peierls tim at peierls.net
Wed Feb 21 22:56:23 EST 2007

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
> optimizations.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070221/49e005e1/attachment-0001.html 

More information about the Concurrency-interest mailing list