[concurrency-interest] dealing with people thatquestionvisibility problems
dcholmes at optusnet.com.au
Wed Feb 21 23:46:36 EST 2007
My comments were in response to the comment re the research professor making
all fields final/volatile - and that was not in the context of a framework
like Spring. Or if it was then it wasn't clear that was the context.
The fact this might be necessary with some frameworks and not others simply
reflects the sorry state of some frameworks with regard to their
thread-safety (for want of a better term) properties.
From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Tim Peierls
Sent: Thursday, 22 February 2007 1:56 PM
To: dholmes at ieee.org
Cc: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] dealing with people
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