Mailing-List: contact dev-help@devicemap.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@devicemap.apache.org
Received-SPF: pass (nike.apache.org: domain of volkan.yazici@gmail.com
 designates 209.85.215.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <86wjeix8pap79lxoxqmd84l4.1419953466053@email.android.com>
References: <86wjeix8pap79lxoxqmd84l4.1419953466053@email.android.com>
Date: Tue, 30 Dec 2014 17:06:05 +0100
Message-ID: 
 <CAP7pH7sJ_vuMpJHqNxGHZd-JQxohz6nXXeKydK+tiNuYqeHuyw@mail.gmail.com>
Subject: Re: Pattern.rank
From: =?UTF-8?B?Vm9sa2FuIFlhesSxY8Sx?= <volkan.yazici@gmail.com>
To: "dev@devicemap.apache.org" <dev@devicemap.apache.org>
Content-Type: multipart/alternative; boundary=001a113368d40e9b43050b712b48

--001a113368d40e9b43050b712b48
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Honestly, I believe JMM is *rocket science* and I am not an expert on the
subject -- which is also apparent from my wrong alarm. That being said,
these materials might get you warmed up:

   - TSM01-J. Do not let the this reference escape during object
   construction
   <https://www.securecoding.cert.org/confluence/display/java/TSM01-J.+Do+n=
ot+let+the+this+reference+escape+during+object+construction>
   - TSM03-J. Do not publish partially initialized objects
   <https://www.securecoding.cert.org/confluence/display/java/TSM03-J.+Do+n=
ot+publish+partially+initialized+objects>
   - Safe Object Publication in Java
   <http://vlkan.com/blog/post/2014/02/14/java-safe-publication/>
   - Safe Publication and Safe Initialization in Java
   <http://shipilev.net/blog/2014/safe-public-construction/>

Let me briefly explain what I understand from the Pattern class issue:

class A {
    final int x, y;
    A(int x) { this.x =3D x; this.y =3D f(); }
    int f() { return x; }
}

This is totally safe, since "final" fields enforce a happens-before
relationship.

class A {
    int x, y;
    A(int x) { this.x =3D x; this.y =3D f(); }
    int f() { return x; }
}

This is also safe, because JMM allows optimizations (e.g. assignment
re-ordering) such that a single-threaded execution should always produce
the same output.

class A {
    static A a;
    *int* x;
    A(int x) { this.x =3D x; a =3D this; }
}

This is unsafe, we leaked "this" prior to initialization. Another thread
accessing A.a instance might observe an uninitialized x.

I think I mis-interpreted the "An object is in a predictable, consistent
state only after its constructor returns" statement from JCP book. I will
consider this case more thoroughly tomorrow, maybe even write a blog post
about it.

On Tue, Dec 30, 2014 at 4:31 PM, Reza Naghibi <
reza.naghibi@yahoo.com.invalid> wrote:

> Is this because the JVM may optimize and reorder the code? So I come from
> a c and assembly background, just trying to better understand... :)
>
>
>
>
> <div>-------- Original message --------</div><div>From: Volkan Yaz=C4=B1c=
=C4=B1 <
> volkan.yazici@gmail.com> </div><div>Date:12/30/2014  9:55 AM  (GMT-05:00)
> </div><div>To: dev@devicemap.apache.org </div><div>Cc:
> </div><div>Subject: Re: Pattern.rank </div><div>
> </div>You're right Reza, it is not unsafe. I confused it with leaking
> "this" in
> ctor -- even in that case "final" modifier of the fields impose the
> happens-before relationship constraint, which is also fine. It needed qui=
te
> some debate on FreeNode to get things resolved. Sorry for the wrong alarm=
.
>
>
> On Tue, Dec 30, 2014 at 3:04 PM, Reza Naghibi <
> reza.naghibi@yahoo.com.invalid> wrote:
>
> > Hmm... can you provide a reference or some kind of example showing that=
 a
> > single threaded read after write is unreliable? I'm thinking if this is
> > true, huge swaths of programs would be deemed unsafe since read after
> write
> > is quite a common memory pattern... :) No?
> >
> >
> >
> > <div>-------- Original message --------</div><div>From: Volkan Yaz=C4=
=B1c=C4=B1 <
> > volkan.yazici@gmail.com> </div><div>Date:12/30/2014  8:31 AM
> (GMT-05:00)
> > </div><div>To: dev@devicemap.apache.org </div><div>Cc:
> > </div><div>Subject: Re: Pattern.rank </div><div>
> > </div>A related excerpt from the Java Concurrency in Practice: "An obje=
ct
> > is in a
> > predictable, consistent state only after its constructor returns, ..." =
In
> > its current form of Pattern:
> >
> > Pattern(...) {
> >     ...
> >     this.boost =3D boost;
> >     this.rank =3D rank();
> > }
> >
> > public long rank() {
> >     // access to this.boost
> > }
> >
> >
> > this.boost might not have been completely initialized when rank() tries
> to
> > access to it.
> >
> > On Tue, Dec 30, 2014 at 2:14 PM, Reza Naghibi <
> > reza.naghibi@yahoo.com.invalid> wrote:
> >
> > > Interesting... you cannot access instance variables in the constructo=
r?
> > >
> > > Also, this hasn't been fully implemented. Boost is going to be a DRR
> > > pattern attribute which will allow 1 pattern to be configured to rank
> > > higher than another.
> > >
> > >
> > >
> > >
> > > <div>-------- Original message --------</div><div>From: Volkan YAZICI=
 <
> > > volkan.yazici@gmail.com> </div><div>Date:12/30/2014  4:41 AM
> > (GMT-05:00)
> > > </div><div>To: dev@devicemap.apache.org </div><div>Cc:
> > > </div><div>Subject: Pattern.rank </div><div>
> > > </div>Hi,
> > >
> > > I have an objection and a question about Pattern class in Java client=
.
> > >
> > > *Objection:* Pattern.rank() instance method gets called in ctor and
> > > accesses to instance variables, which might not have been initialized
> yet
> > > due to JMM semantics. I propose to fix it as in DMAP-115
> > > <https://issues.apache.org/jira/browse/DMAP-115>.
> > >
> > > *Question:* Shall we remove boost option on Pattern ctor? It is neith=
er
> > > used, nor available in .NET client.
> > >
> > > Best.
> > >
> >
>

--001a113368d40e9b43050b712b48--