Re: JMM- conservative and formal point of view.

On 05/16/2018 09:19 PM, John Hening wrote: > By the way, in your transcription you said: > | >     inta; > >     volatilebooleanready =false; > >     voidactor(IntResult1r){ >         while(!ready){}; >         r.r1 =a; >     } > >     voidobserver(){ >         a =41; >         a =42; >        

Re: JMM- conservative and formal point of view.

Caveat: when the *outcome* would be equivalent to some allowed JMM execution. It does not mean the actual implementation should issue machine instructions in any given order. Obviously yes. Aleksey, thanks for your response and presentation. I need to rethink a whole JMM, unfortunately :(.

Re: JMM- conservative and formal point of view.

On 05/16/2018 07:33 PM, John Hening wrote: > Subject: JMM- conservative and formal point of view. There is no "conservative" JMM point of view. There is JSR 133 Cookbook for Compiler Writers that describes the conservative implementation, but it is not the JMM itself. Reductio ad absurdum:

JMM- conservative and formal point of view.

The following picture comes from: https://shipilev.net/blog/2014/jmm-pragmatics/ As I understand this slide points that JMM does not constitute that a volatile write does not work as a (Load/Store)Store barrier, and it doesn't in

synchronized and ReentrantLock are REALLY the same?

Hi guys! probably this one should be more a concurrency-interest question, but I'm sure that's will fit with most of the people around here as well :) I was looking to how ReentrantLock and synchronized are different from a semantic point of view and I've found (there are no experimental proofs