Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Peter <jini@zeus.net.au>
Reply-To: Peter <jini@zeus.net.au>
To: dev@river.apache.org
Subject: Re: VOTE: add Startable to Jini specification
References: <1387274583.7396.13.camel@Nokia-N900>
	 <01DC5F42-670F-4458-B1E5-8FE50B3A28A3@stratuscom.com>
	 <1387306701.8540.23.camel@Nokia-N900>
	 <3FF1CDAE-3D35-4640-AF8A-6A0BC992A08C@stratuscom.com>
	 <1387356749.10045.11.camel@Nokia-N900>
	 <CAMPUXz8w2UGdGOQoaFy1Msb5nxQ56kj=EW6PseOt_T4D6QwR1g@mail.gmail.com>
	 <1387361916.10544.5.camel@Nokia-N900> <52B1811E.3020909@acm.org>
	 <1387366936.10790.16.camel@Nokia-N900>
	 <1387370542.10790.28.camel@Nokia-N900>
	 <B3A3F03C-B544-47E6-9A3B-DF75A018A43C@stratuscom.com>
	 <1387379542.10790.62.camel@Nokia-N900>
	 <1387413765.11482.5.camel@Nokia-N900>
	 <6C1CA208-98BF-415F-8F65-A4D6800E39E8@stratuscom.com>
	 <CAMPUXz-cEAAQ=OzVic9HF3mB9_ZgsCEwhLxN4TarjMCE9QcBxw@mail.gmail.com>
	 <1387498686.13390.6.camel@Nokia-N900> <1387504487.13767.5.camel@Nokia-N900>
	 <47E98176-3F2B-43B6-831B-5F45E5D821AD@stratuscom.com>
	 <1387514976.13913.5.camel@Nokia-N900>
	 <CAMPUXz-cKDyPMY6DZGQn5TXLK0Hq_Kq0F6EbqP+Vc6gYpDjDdA@mail.gmail.com>
	 <52B48E89.2030604@acm.org>
	  <CAMPUXz-uJNOhwCzhANaNRN92seFZiWK33wNZQgLMccKF+JMWew@mail.gmail.com>
In-Reply-To: 
 <CAMPUXz-uJNOhwCzhANaNRN92seFZiWK33wNZQgLMccKF+JMWew@mail.gmail.com>
Content-Type: multipart/alternative; boundary="=-KfuFk9OxcLKPo3PrVWop"
Date: Sat, 21 Dec 2013 08:38:00 +1000
Message-Id: <1387579080.15184.5.camel@Nokia-N900>
Mime-Version: 1.0

--=-KfuFk9OxcLKPo3PrVWop
Content-Type: text/plain; charset=utf-8
Content-ID: <1387579079.15184.2.camel@Nokia-N900>
Content-Transfer-Encoding: 7bit

----- Original message -----
> "Comments like `Jini 2.x doesn't seem to have such an issue even with the
> "serious flaw" you
> claim?` are typical of an experimental approach."
> 
> They might well be typical but in this case my statement has nothing to
> do with an experimental approach.
> 
> [ In fact, you could have asked me if I'm advocating such a thing
> directly, why didn't you? ]

Perhaps you were unaware or hadn't realised, but Patricia nailed it, you're using an experimental approach.

Now it's up to you to decide, the blue pill or the red pill?

> 
> Here's what I'm asking for: A clear statement of what problem we're
> fixing.

I'll do my best to put it simply:

Our starter kit, Phoenix and Activation, all use reflective constructor signatures to create services.  Although you can't define an interface for a constructor, these are the closest equivalent 

The proposed interface allow our services to use final fields simply by allowing exporting and threads that access internal shared state to be delayed until after the constructor completes.

For examples, use the diff view via our svn website on the qa_refactor branch.  All services, including those in the qa suite have been fixed / converted.

The proposed solution is simple and complete.


 All I'm hearing at the moment is that if some thread other than
> the constructing thread reads a final before the constructing thread is
> done, bad things can happen. That is entirely true and in alignment with
> the JMM, a statement of the obvious if you will.
> 
> BUT
> 
> The critical aspect is not releasing the reference to an object to
> another thread before construction completes but that other thread
> READING that final variable using that reference before construction is
> complete.
> 
> i.e. there is nothing wrong with releasing a reference, it's about what
> you do with it and when.
> 
> SO
> 
> What I'm interested in hearing is: What code in the JSTK is getting hold
> of a reference prior to construction completing and then reading from
> it? Or what code could and how? Perhaps, for example, we're worried about
> something an exporter might do (of course you could stipulate that it not
> access the object for any other reason than to dispatch a remote
> request)? Or maybe a JoinManager (and what if I wanted the reference to
> my JoinManager to be final)?
> 
> AND
> 
> Does the change we're discussing actually constitute a band-aid or a
> complete solution? Is a new interface enough or do we need to go fix up
> some other classes like JoinManager and such to do this properly?
> 
> BECAUSE
> 
> I care about fixing the right problem the right way...
> 
> 
> 
> 
> On 20 December 2013 18:38, Patricia Shanahan <pats@acm.org> wrote:
> 
> > On 12/20/2013 1:25 AM, Dan Creswell wrote:
> > ...
> > 
> > And "serious flaw" - really? How might you judge that as the case?
> > Have we
> > > got a serious service-startup problem? Jini 2.x doesn't seem to have
> > > such an issue even with the "serious flaw" you claim? Perhaps this
> > > "serious flaw" has come into being because of all the other work
> > > you've done since Jini 2.x (and I'm not saying the work isn't
> > > valuable)? If that is so, perhaps that is because you have changed
> > > the contract against which a service is written? If so, I would
> > > suggest you would be having a vote on modifying the contract not
> > > adding an interface.
> > > 
> > > ...
> > 
> > I think there is a big picture question that underlies all this. There
> > are two, potentially complementary, approaches to thread safety,
> > experiment and theory. Each has advantages and disadvantages.
> > 
> > In the pure experimental approach, the only thread safety issues that
> > require change are those that manifest as bugs in some known test. The
> > upside is that one can do strictly test driven development, where every
> > change fixes a test failure. The downside is that the resulting code
> > can be fragile - an apparently irrelevant change can shift a latent
> > bug to causing a test failure. The code may run fine on small, lightly
> > loaded systems, but fail on larger systems especially if there is
> > contention for processors and/or memory.
> > 
> > In a theory driven approach, the objective is to make the code
> > thread-safe by design. It requires changes to conform, in the case of
> > Java, to the JMM, regardless of whether the issue manifests as a test
> > failure. The upside is that the resulting code should be more robust -
> > mere timing changes, or shifts in the locations of page and cache line
> > boundaries, cannot cause failures. The downside is that it requires
> > changes that are not necessarily supported by a failing test case.
> > 
> > My own reading of River code convinced me that it was largely in an
> > experimental state, with multi-thread issues that were not being fixed
> > because they did not cause known test failures. Comments like `Jini 2.x
> > 
> > doesn't seem to have such an issue even with the "serious flaw" you
> > claim?` are typical of an experimental approach.
> > 
> > As I understand the big picture, Peter is pushing a change to a more
> > theory-based approach.
> > 
> > Shifting the balance from experimental towards theory involves a risk
> > of cascading problems because making one change that affects the
> > relationships between threads can open up a sequence of events that
> > triggers an apparently unrelated bug.
> > 
> > I think the PMC should discuss and decide on whether to make the change
> > to the theory based approach. If I were still a PMC member I would be
> > strongly in favor, but it is not up to me. A lot of decisions,
> > including this vote, would be obvious and non-controversial in the
> > light of a definite policy, either way, on that issue.
> > 
> > Patricia
> > 
> > 


--=-KfuFk9OxcLKPo3PrVWop--