[concurrency-interest] Non-volatile reads

Alex Otenko oleksandr.otenko at gmail.com
Wed Apr 26 11:32:03 EDT 2017


You are making many assumptions about the behaviour of the compiler without a reference where you got them from. Not that I am asking for references, just pointing out how early your reasoning went wrong.

JMM only guarantees happens-before edges between writing to x (x=newVal) and reading from x (return x), if you have program order between them (same thread writes, then reads), or a happens-before edge between some other instructions - one instruction appearing in program order after write to x and one instruction appearing before reading x in program order.

For example, if you aren’t reading from y as regularly as you read from x in the thread that reads x, JMM does not guarantee anything about visibility of x.


Alex

> On 26 Apr 2017, at 16:11, Bobrowski, Maciej <Maciej.Bobrowski at morganstanley.com> wrote:
> 
> 
> Let’s consider the class:
>  
> Foo{
>  
>    int x = 0;
>    volatile int y = 0;
>  
>   void write(int newVal) {
>      x = newVal;
>      y = newVal;
>   }
>  
>   int getX(){ return x; }
>  
> }
>  
> I would like to assume that the compiler is NOT going to rewrite the getX() to a constant, and it will actually read it from memory/cache and not from a register. Let’s assume one thread is periodically calling write with increasing value, and one other thread is reading x.
>  
> Q1. Volatile forces ordering and visibility of writes (x and y) across processors. As far as I see it, when volatile write happens, all store buffers of that core will be flushed in an exclusive manner (by obtaining exclusive flag on the processor). The push will invalidate all other cores cache lines that are related to the data written (not sure how though..). Is that correct?
>  
> Q2. Given the above, after the flushing of the buffers happen, the other thread will be forced to re-read x from main mem (or L3 cache) and update its local value,, effectively seeing the new value. Correct?
>  
> Q3. Even if y was not volatile, on x-86 the store buffers would eventually be flushed, so eventually reading process would see an updated value of x, perhaps not latest but non-zero value?
>  
> Thanks for any pointers/comments.
> 
> 
> 
> NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers <http://www.morganstanley.com/disclaimers>  If you cannot access these links, please notify us by reply message and we will send the contents to you. By communicating with Morgan Stanley you consent to the foregoing and to the voice recording of conversations with personnel of Morgan Stanley.
> 
> 
> 
> 
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu <mailto:Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170426/c8147d61/attachment-0001.html>


More information about the Concurrency-interest mailing list