[concurrency-interest] dealing with people that questionvisibility problems
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
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...
More information about the Concurrency-interest