[External] : Re: Why is mark read as MO_RELAXED in read_stable_mark()?

[Roman Kennke]

>>> Looking at the uses of read_stable_mark() I would say that 
>>> FastHashCode and get_lock_owner() should have acquire semantics to 
>>> match the implied release semantics used when there is inflation and 
>>> those methods have to read fields of the monitor. I'm not convinced 
>>> we can rely on any address dependency for semantics in shared code - 
>>> and it seems too subtle a point even if we can.
>>
>> Ok, I agree.
>>
>>> The other uses don't need acquire semantics
>>
>> Why do you think so?
>>
>> I see a use in current_thread_holds_lock(), and how is that different 
>> from get_lock_owner() ? It also reads a field of the monitor after 
>> loading the header word.
> 
> Because that thread is only interested in correctly seeing values 
> written by itself. It can't get any kind of false positive. If it is the 
> owner it must see its own writes; if it is not the owner it can't see 
> itself incorrectly listed as the owner.

Right. Is it reasonable to make the distinction for that single case, 
though? Adding acquire semantics should not make much of a difference 
(if at all) to performance, in light of the other things that the method 
does?

Roman