[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-core-libs-dev
Subject:    Re: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cac
From:       Vladimir Ivanov <vladimir.x.ivanov () oracle ! com>
Date:       2014-05-28 10:48:38
Message-ID: 5385BF06.5090808 () oracle ! com
[Download RAW message or body]

Looks good.

It should be safe to sync on MTF instance since it's not accessible 
outside (MTF and MT.form() are package-private).

Best regards,
Vladimir Ivanov

On 5/28/14 1:49 PM, Tobias Hartmann wrote:
> Hi,
>
> thanks everyone for the feedback!
>
> @Remi: I agree with Paul. This is not a problem because if the normal
> read sees an outdated null value, a new LambdaForm is created and
> setCachedLambdaForm(...) is executed. This will guarantee that the
> non-null value is seen and used. The unnecessary creation of a new
> LamdaForm is not a problem either.
>
> @John: I added the code that you suggested to simulate CAS. Please find
> the new webrev at:
>
> http://cr.openjdk.java.net/~anoll/8005873/webrev.02/
>
> Sorry for the delay, I was on vacation.
>
> Thanks,
> Tobias
>
> On 19.05.2014 20:31, John Rose wrote:
>> On May 16, 2014, at 4:56 AM, Tobias Hartmann
>> <tobias.hartmann@oracle.com> wrote:
>>
>>> Is it sufficient then to use synchronized (lambdaForms) { ... } in
>>> setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)?
>> Yes, that is how I see it.  The fast path is a racy non-volatile read
>> of a safely-published structure.
>>
>> (If safe publication via arrays were broken, java.lang.String would be
>> broken.  But the JMM is carefully designed to support safe publication
>> of array elements, and through array elements.)
>>
>> — John
>
[prev in list] [next in list] [prev in thread] [next in thread]