RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix

[David Holmes]

On 17/11/2020 8:14 pm, Stefan Karlsson wrote:
> On Tue, 17 Nov 2020 07:26:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
> 
>>> Mutex::try_lock has to allow for the possibility that the PlatformMutex::try_lock allows recursive locking.
>>>
>>> Added additional commentary on the semantics provided by Mutex and the PlatformMutex classes.
>>>
>>> Testing: GHA, mach5 tiers 1-3
>>
>> Hi David,
>>
>> LGTM. Minor remarks below.
>>
>> Thanks, Thomas
> 
>> Using Atomic::load is a good idea just from a code hygiene perspective,
>> but doesn't change the raciness.
> 
> My point was that because this is a racy read we _should_ use Atomic::load.

And my point is that Atomic::load makes no difference to the raciness. 
The Atomic::load is just how we now wrap/hide the fact the field should 
be treated as volatile and not optimised in any way by the compiler. And 
on that note I should point out that the Mutex code has not been 
converted to that form and raw reads of _owner are all over the place. 
So I'm actually reluctant to add in this single use of Atomic::load. 
Happy to file a RFE to update all the Mutex code that way though.

Thanks,
David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1247
>