[concurrency-interest] dealing with people that questionvisibility problems

Tim Peierls tim at peierls.net
Thu Feb 22 14:29:04 EST 2007

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

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.

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

More information about the Concurrency-interest mailing list