river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: VOTE: add Startable to Jini specification
Date Fri, 20 Dec 2013 20:34:11 GMT
Pat,

I'd like to invite you back, even if it's just in an advisory capacity.

I think we can all benefit from your experience.

So far you've managed to explain everything so eloquently, the rest of us look like children
fighting over toys.

Regards,

Peter.

----- Original message -----
> 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
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message