[concurrency-interest] dealing with people that questionvisibility problems

Tim Peierls tim at peierls.net
Thu Feb 22 09:32:07 EST 2007

On 2/22/07, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
> 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 it is extremely likely that the Spring ApplicationContext as it
stands does provide the requisite synchronization for singleton beans. There
are several problems:

1. There is no centralized documentation in the Spring source of the
synchronization policy used to obtain the visibility guarantees, so future
well-meaning developers would have no warning against, say, changing the
bean registration machinery to use a lock-free map.

2. There are other types of scope for beans than singleton, and I haven't
been able to convince myself that ApplicationContext provides visibility
guarantees for beans in all of these other scopes. Should I have to mark my
beans with "only deploy as singleton"?

3. There are other implementations of the BeanFactory interface that aren't
ApplicationContexts. Should I have to mark my beans with "only deploy in

4. There are other container frameworks than Spring. Should I have to mark
my beans with "works in Spring, might not work in other frameworks"?

I've making these arguments for months, and by now it probably sounds as
though I have something against Spring. For the record: I love Spring, I use
Spring, and I wholeheartedly recommend it.  I have not been pleased,
however, with the reaction of some Spring developers to my concern, which
has been to deny that there might be problem and to posture ("tens of
thousands of developers unhesitatingly trust Spring, so why can't you?").

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.

I would agree completely if it weren't for the way volatile is such a good
match for the setter-injection problem (under the assumption that there is a
problem). Setter-injected fields are usually independent of each other, so
atomicity is less likely to be a concern.

However, Joe reminded me privately that there has been some discussion of
using annotations to mark "wannabe final" fields that can't be initialized
in the constructor but are effectively final once the bean is published in a
particular way, e.g., via a Spring ApplicationContext. I'm hoping those who
took part in that discussion will chime in here.

Using an annotation would make it clear that the setter should not be called
after publication, and it would allow an annotation processor to insert
appropriate synchronization if necessary. (If you think that's an abuse of
annotation processors, then just use the annotation as a documentation aid
and insert the synchronization manually.)

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

I'm not saying don't document it. But if you declare globally that volatile
-- unless marked otherwise -- means "setter-injected read-only" (in the
absence of a standard annotation for this), that should make the code easy
to understand.

I'm not trying to encourage the use of volatile in any other context.

In my view, adorning code with volatile just-in-case there might be a
> visibility problem is worse than doing nothing.

I disagree. Make your code correct and then worry about performance.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070222/27136ff9/attachment.html 

More information about the Concurrency-interest mailing list