«

Lew wrote:

Knute Johnson wrote:
> Lew:
>
> That's an excellent article, thanks for finding that.

Google is my friend.

-Lew

mei wrote:
> Here it is even though it seems it is outdated:
> http://java.sun.com/docs/books/tutor...cy/atomic.html
> "Atomic actions cannot be interleaved, so they can be used without fear
> of thread interference. However, this does not eliminate all need to
> synchronize atomic actions, because memory consistency errors are still
> possible."

They are talking about "happens-before" relationships.

- Lew

Lew a écrit :
> mei wrote:
>> Here it is even though it seems it is outdated:
>> http://java.sun.com/docs/books/tutor...cy/atomic.html
>> "Atomic actions cannot be interleaved, so they can be used without
>> fear of thread interference. However, this does not eliminate all need
>> to synchronize atomic actions, because memory consistency errors are
>> still possible."
>
> They are talking about "happens-before" relationships.
>
> - Lew

Ok, you are right: As far as I understand it, what the Sun tutorial
explains about the happens-before relationship matches with what is said
in the IBM article. Thus the tutorial is also up-to-date.
But still the tutorial claims that this new semantic of volatile is not
enough to prevent from memory consistency errors. So I think my initial
question is still unanswered, or am I missing something?

mei wrote:
> As far as I understand it, what the Sun tutorial
> explains about the happens-before relationship matches with what is said
> in the IBM article. Thus the tutorial is also up-to-date.
> But still the tutorial claims that this new semantic of volatile is not
> enough to prevent from memory consistency errors. So I think my initial
> question is still unanswered, or am I missing something?

See Chris Uppal's answer in this thread. It includes an example of what might
be inconsistent.

- Lew

Chris Uppal wrote:
> Lew wrote:
>
>> According to
>> <http://www-128.ibm.com/developerworks/java/library/j-jtp03304/>
> [...]
>> "The JSR 133 Expert Group decided that it would be more sensible for
>> volatile reads and writes not to be reorderable with any other memory
>> operations ... Under the new memory model, when thread A writes to a
>> volatile variable V, and thread B reads from V, any variable values that
>> were visible to A at the time that V was written are guaranteed now to be
>> visible to B."
>
> Can anyone point me to the passages in JLS3 which imply that. My own study of
> the new stuff has been patchy (and reluctant), but I haven't yet seen anything
> to make the following wrong. (I'm not claiming it /isn't/ wrong, only asking
> for corroboration, or -- better -- refutation).
>
> With the above caveat. Given a non-local volatile variable:
>
> volatile int[] volatileField;
>
> It seems to me that if one thread does the following:
>
> int[] local = new array[2];
> local[0] = 100;
> local[1] = 200;
> volatileField = local;
>
> then there are only so many things that another thread, subsequently reading
> the volatileField's contents, is guaranteed to see.
>
> I believe the following to be guaranteed:
>
> volatileField is not null.
> volatileField refers to an int[] array of length 2.
> volatileField[0] is either 0 or 100
> volatileField[1] is either 0 or 200
>
> However, I haven't yet found anything to convince me that any of the following
> are illegal:
>
> volatileField[0] == 0 && volatileField[1] == 0
> volatileField[0] == 100 && volatileField[1] == 0
> volatileField[0] == 0 && volatileField[1] == 200
> volatileField[0] == 100 && volatileField[1] == 200
>
> The wording in JLS3 seems to be quite specific about the happens
> before-relationship[*] as it applies to volatiles, and it only seems to refer
> to the value of the volatile /itself/, not to any other actions.
>
> It may be that the later stuff (causality, etc) in the JLS3 clears this up, but
> as far at the HB relation goes, I can't see that the visible contents of the
> array are fully constrained.
>
> -- chris
>
>[*] which I think would be better named: must-not-be-seen-to-happen-after.
>
>

I think if you look at this situation as class with two int fields
rather than an int[] you will see that the fields are not volatile
unless declared so. So while the variable volatileField would indeed
reference the correct int[] there would be no synchronization of the
array elements across threads.

Or at least that is what I think today . Then again it could all be
different with arrays.

--

Knute Johnson
email s/nospam/knute/

Knute Johnson wrote:
> Chris Uppal wrote:
>> Lew wrote:
>>
>>> According to
>>> <http://www-128.ibm.com/developerworks/java/library/j-jtp03304/>
>> [...]
>>> "The JSR 133 Expert Group decided that it would be more sensible for
>>> volatile reads and writes not to be reorderable with any other memory
>>> operations ... Under the new memory model, when thread A writes to a
>>> volatile variable V, and thread B reads from V, any variable values that
>>> were visible to A at the time that V was written are guaranteed now
>>> to be
>>> visible to B."
>>
>> Can anyone point me to the passages in JLS3 which imply that. My own
>> study of
>> the new stuff has been patchy (and reluctant), but I haven't yet seen
>> anything
>> to make the following wrong. (I'm not claiming it /isn't/ wrong, only
>> asking
>> for corroboration, or -- better -- refutation).
>>
>> With the above caveat. Given a non-local volatile variable:
>>
>> volatile int[] volatileField;
>>
>> It seems to me that if one thread does the following:
>>
>> int[] local = new array[2];
>> local[0] = 100;
>> local[1] = 200;
>> volatileField = local;
>>
>> then there are only so many things that another thread, subsequently
>> reading
>> the volatileField's contents, is guaranteed to see.
>>
>> I believe the following to be guaranteed:
>>
>> volatileField is not null.
>> volatileField refers to an int[] array of length 2.
>> volatileField[0] is either 0 or 100
>> volatileField[1] is either 0 or 200
>>
>> However, I haven't yet found anything to convince me that any of the
>> following
>> are illegal:
>>
>> volatileField[0] == 0 && volatileField[1] == 0
>> volatileField[0] == 100 && volatileField[1] == 0
>> volatileField[0] == 0 && volatileField[1] == 200
>> volatileField[0] == 100 && volatileField[1] == 200
>>
>> The wording in JLS3 seems to be quite specific about the happens
>> before-relationship[*] as it applies to volatiles, and it only seems
>> to refer
>> to the value of the volatile /itself/, not to any other actions.
>>
>> It may be that the later stuff (causality, etc) in the JLS3 clears
>> this up, but
>> as far at the HB relation goes, I can't see that the visible contents
>> of the
>> array are fully constrained.
>>
>> -- chris
>>
>>[*] which I think would be better named:
>> must-not-be-seen-to-happen-after.
>>
>>
>
> I think if you look at this situation as class with two int fields
> rather than an int[] you will see that the fields are not volatile
> unless declared so. So while the variable volatileField would indeed
> reference the correct int[] there would be no synchronization of the
> array elements across threads.
>
> Or at least that is what I think today . Then again it could all be
> different with arrays.
>

And I found some more interesting things. Look at AtomicBoolean in the
docs and follow the link 'java.util.concurrent.atomic'. It has a
discussion of the Atomic??? classes and especially see
AtomicIntegerArray. I still think that it would require synchronization
to prevent memory consistency errors however.

--

Knute Johnson
email s/nospam/knute/