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 Tue, 24 Dec 2013 06:24:07 GMT
People may also find the following interesting:




----- Original message -----
> On Dec 20, 2013, at 2:49 PM, Dan Creswell <dan.creswell@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

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