[concurrency-interest] Volatile happens before question

Boehm, Hans hans.boehm at hp.com
Wed Jan 18 12:36:21 EST 2012

> From: Zhong Yu [mailto:zhong.j.yu at gmail.com]
> On Tue, Jan 17, 2012 at 5:13 PM, Boehm, Hans <hans.boehm at hp.com> wrote:
> > Another way to look at this is that compiler reordering that is only
> observable by programs with data races is generally allowed.  The
> program below clearly has an inherent data race on b.  If you make b
> volatile, the data race, and the problem, go away.
> Not by the definitions in the book.
> Volatile r/w can form a data race, if there is neither hb(r,w) nor
> hb(w,r), which is possible when r is before w in synchronization
> order.
Interesting observation.  But I think that's clearly yet another bug in the specification.  It's called a DATA race because it involves data, not synchronization (e.g. volatile) operations.  If this were correct, essentially every program containing volatiles would have data races.

This part of the spec really needs an overhaul.  A technical reason for that is that we know that there are serious fundamental and unsolved problems with the treatment of data races (as they should be defined), and it's unclear we can make enough progress without resolving those.

> P.S. Reading JLS,  the wording of "allowed to observe" (17.4.5) is
> very misleading; it is defined only in term of happens-before order,
> meaning a volatile read can be "allowed to observe" a later volatile
> write.
I don't think so.  If it did, the write would happen before the read, which would lead to a contradiction.


> Zhong Yu

More information about the Concurrency-interest mailing list