[concurrency-interest] Concurrent Read/Write without Synchronization
mettafort at gmail.com
Fri Dec 17 23:12:54 EST 2010
Thanks Joe. Our understanding seems correct - that you would need some form
of volatile read/write to ensure the visibility of a state change to a word
sized value in one process/core is visible in the other cores accessing the
shared memory reference?
There seems to be confusing descriptions on what volatiles are used for. I
work in both .Net and Java, and for the most part the differences around
this type of thing have been small. My understanding was .net had the same
approach - a write is atomic but could be sitting in some cache of a
processor, and a thread running on another core/processor could still be
seeing an old value. Not sure where MESI etc comes in or resolves (or
On Fri, Dec 17, 2010 at 8:46 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
> see below
> On Fri, Dec 17, 2010 at 6:29 PM, Insane Membrane wrote:
>> Could someone please answer this simple question for me? I have two
>> threads, A and B, and they share an object P that has an integer property
>> called x. The first question is, if A sets x to a value, but B only ever
>> reads x, will B ALWAYS see the latest value of x? So A does x = x + 1.
>> Will B always see x with the new value? We were under the impression the
>> latest value could still be sitting in the cache of A, but not visible in B.
>> This would be one reason for the volatile or interlocked operations?
> Yes, the JMM says you need volatile (or synchronization) to ensure that B
> reads the most recent value written to x.
>> Similarly, if we have an object reference and we set it onto some
>> public/global reference, all threads would always see whatever had been
>> written to this global reference IMMEDIATELY, without any needs for
>> synchronization or interlocked?
> Every value is written by some thread. It doesn't matter how accessible
> the value is. This is identical to your first example.
>> This is assuming the int is 32bit on a 32bit machine, and the reference is
>> the same too.
>> Thank you,
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest