"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? ] Here's what I'm asking for: A clear statement of what problem we're fixing. 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 <p...@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 > >
