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 >
