[concurrency-interest] Concurrent Read/Write without Synchronization

Insane Membrane 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
complicates this)?

Thans again!

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:
>
> Hi-
>>
>> 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,
>>
>> mf.
>>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20101217/3c47e099/attachment.html>


More information about the Concurrency-interest mailing list