[concurrency-interest] dealing with people that questionvisibility problems
gregg at cytetech.com
Thu Feb 22 09:16:21 EST 2007
Joe Bowbeer wrote:
> 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.
I think that it's important to realize how much legacy code was written prior to
the existance of such frameworks. There will also be new code written without
such frameworks. It's that programming in the RAW that is creating the greatest
> 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.
The professor is involved in producing research conducting software systems. He
is trying to maintain some amount of coding standard that creates more
predictable results I suppose. It's just interesting to me that this is the
perspective that is comming out of peoples experiences. I'm not at all
condoning the rampant use of volatile. I'm just trying to stress that not using
volatile creates much less desireable results in the presence of visibility
related software misdesign.
> 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
I think this is a valid point. But in the presense of visiblity related bugs,
it's an argument of "does it work now" vs "will we have problems maintaining
it". Making it work first, is usually the driving force. Only a limited number
of people (from my experience) actually have a desire for perfection over function.
> In my view, adorning code with volatile just-in-case there might be a
> visibility problem is worse than doing nothing.
Well, the issue is that as a casual step in debugging a software misbehavior,
adding volatile will almost always change the behavior of a visibility related
problem. If there is no atomicity issue, it will "fix" the problem.
Developers usually prefer "adding code" to fix a problem to "changing code" to
fix a problem because it has, in general, always been less risky to just tack
something on rather than trying to understand the code and refactor it.
More information about the Concurrency-interest