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
