People may also find the following interesting: http://www.azulsystems.com/blog/cliff/2011-10-17-writing-to-final-fields-via-reflection
Regards, Peter. ----- Original message ----- > > On Dec 20, 2013, at 2:49 PM, Dan Creswell <dan.cresw...@gmail.com> wrote: > > > > 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. > > Okay, this is where it’s important to make sure that everyone is getting > what the JMM says. This is not about “when” but the “order”. If we > have the tasks identified as follows: > > 1. T1 starts to construct O1 > 2. T2 gains reference to O1 via T1 handing it a reference > 3. T1 completes construction of O1 > 4. T2 reads some value from the fields of O1 > > then one could say that the constructor completed before the reference > to O1, by T2. What I think is important to understand, is that you > have to guarantee that will happen with a shared happens before > relationship between T1 and T2. > > Theory based programming is used to make sure this happens. Test base > programming might result in some delay being placed in T2 such that T1 > should always complete. > > I don’t think that there is anyone here that would do such a thing, but > sometimes it happens by mistake. I.e. what if T2 goes to do something > on the network in the test, accessing a nonexistent DNS server which > stalls it and causes the timing to work out okay? What if the 3.5 > second reduction to 2 second reduction that Peter made, opens the window > to T2 using O1 before T1 completes? > > We really do need to fix these things. I’ve made many, many patches to > my private copy of Jini over the years, specifically related to seeing > these kinds of things going on. It’s real stuff. As I’ve said before. > Many of us are being saved by the fences and locks in Vector and > Hashtable which are causing implicit happens-before events which fix > these issues. But, those structures just KILL performance. As we > remove the use of those, as Patricia said, other things are going to > start breaking, and Peter has found that happening all along his path of > exploration of how bad things actually are. > > Gregg Wonderly
