devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reza Naghibi <reza.nagh...@yahoo.com.INVALID>
Subject Re: Pattern.rank
Date Tue, 30 Dec 2014 17:06:07 GMT
Yes, thank you. Those examples made sense.



<div>-------- Original message --------</div><div>From: Volkan Yazıcı
<volkan.yazici@gmail.com> </div><div>Date:12/30/2014  11:06 AM  (GMT-05:00)
</div><div>To: dev@devicemap.apache.org </div><div>Cc:  </div><div>Subject:
Re: Pattern.rank </div><div>
</div>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+not+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+not+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 = x; this.y = 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 = x; this.y = 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 = x; a = 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ıcı
<
> 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 quite
> 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ıcı <
> > 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 object
> > is in a
> > predictable, consistent state only after its constructor returns, ..." In
> > its current form of Pattern:
> >
> > Pattern(...) {
> >     ...
> >     this.boost = boost;
> >     this.rank = 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 constructor?
> > >
> > > 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 neither
> > > used, nor available in .NET client.
> > >
> > > Best.
> > >
> >
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message