On Wed, Jan 18, 2012 at 11:36 AM, Boehm, Hans <hans.boehm at hp.com> wrote:
>> 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.
So basically almost all Java programs are not "correctly
synchronized", that's funny.
> 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.
It shouldn't be allowed to observe, in the plain English sense,
because it's barred by synchronization-order consistency
requirement(17.4.7).
In JLSv3, the phrase "allowed to observe" was italic; still, it was a
badly chosen term. In JLS/SE7 it's not even italic, making it worse.
Zhong Yu