[concurrency-interest] dealing with people that question visibility problems

Joe Bowbeer joe.bowbeer at gmail.com
Thu Feb 22 17:13:45 EST 2007


Observing all the effort that goes into implementing and documenting
thread-safe single-assign fields in Java, I definitely 'get' the
motivation behind the explicit single-assign variables of declarative
concurrency. As for whether to add 'volatile' or not, I like to
aggressively refactor and eliminate unneeded code. Uncertainty leads
to rot. If I'm certain a volatile isn't needed, I remove it, and then
my motto is "Show me the bug". (Bugs are a great learning opportunity;
if something's going to fail then it should fail fast and often.) If
I'm not certain a volatile is needed then resolving that uncertainty
is my primary concern.

On 2/22/07, Tim Peierls <tim at peierls.net> wrote:
> On 2/22/07, Hanson Char <hanson.char at gmail.com> wrote:
> >
> > I disagree. Make your code correct and then worry about performance.
> > >
> >
> > If that's the case wouldn't it be nice if volatile was the default
> > behavior, and (an imaginary) "nonvolatile" be the keyword that needs to be
> > explicitely specified ?
> >
> > :)
> >
>
> Given the smiley, you're probably not asking this seriously, but my serious
> answer is no, it would not be nice. Class invariants in general involve
> multiple fields, so defaulting to volatile would be insufficient in the
> general case.
>
> My (grudging) use of volatile is for independent setter-injected fields. I
> would prefer to have a standard annotation to mark "effectively final"
> ("read-only-after-publication"?) fields, but until there is consensus, I'm
> using plain volatile (plus a global note saying what unadorned volatile
> field with setter means in my beans).
>
> (For those of you who play bridge, using volatile in this way is like using
> an artificial conventional bid that coincidentally happens to be a natural
> bid.)
>
> Not to use any kind of synchronization/volatile at all when there is even
> the slightest possibility of a visibility failure seems like a terrible idea
> to me. I'd be interested in hearing why so many people seem think it is
> justified in the case of setter-injection, given the arguments I listed in
> an earlier message.
>
> --tim
>


More information about the Concurrency-interest mailing list