I have not seen any evidence of lack of understanding. I believe there
is a genuine lack of consensus on how to deal with some of these
ordering issues.
In particular, to what extent should River live with code that will
almost always work?
The damage from export-from-constructor with final fields comes if
another thread references the object before it is fully constructed.
Generally, the chain of instructions from the export to another thread
seeing the reference is far longer than the chain of instructions from
the export to the end of the constructor. Almost always, the constructor
will finish first and the code will work.
Personally, I would not want to depend on that, because page faults and
operating system interrupts with resource contention can stretch out a
few instructions to several milliseconds or even seconds.
However, a project like River depends on reaching consensus and that in
turn depends on discussing issues with respect for all points of view.
Patricia
On 12/21/2013 12:50 AM, Peter Firmstone wrote:
I think the real problem is some people haven't been reading up on
concurrency and are insufficiently informed to be able to properly
discuss the issue.
When I don't know something, I either ask someone who does, or I keep my
mouth shut so as not to look like a fool.
It's more a case of, if you behave like a fool long enough to make it
frustrating, that's exactly how you'll be treated.
Sadly it's by people who should know better, who while they may lack an
understanding of the JMM are still very skilled programmers, that's what
makes it frustrating.
Final fields are made visible after construction completes, so when
other threads receive a copy of the object in an unconstructed state,
like they do during export in a constructor, then those threads can
continue to see the incomplete object, rather than the fully constructed
one.
See for yourselves, look at all the final fields in Mercury, then
realise that it's reference escaped during construction. The other
services are also guilty.
That also means that all the remote method invocations wrapped up as
runnable tasks and executed on Mercury's methods in an executor pool
will have also seen parts of Mercury in a partially constructed state.
http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/src/com/sun/jini/mercury/MailboxImpl.java?r1=545310&r2=1552606
If I haven't convinced you, read up, spend some time on the concurrency
interest mail list or ask someone you trust who does know.
Regards,
Peter.
On 21/12/2013 11:10 AM, Greg Trasuk wrote:
(off-list)
Peter:
You’re sounding unprofessional, and you’re missing the fact that
people are giving reasonable and well-thought-out feedback. You seem
to be taking the conversation personally. Perhaps you should take a
few hours off the list and cool down. Things will still be here when
you’ve regained composure.
Best regards,
Greg.
On Dec 20, 2013, at 7:28 PM, Peter<j...@zeus.net.au> wrote:
You just did.
The blue pill.
I prefer the truth, it's easier in the long run.
Feel free to cast your vote.
Peter.
----- Original message -----
Peter,
There's so many things wrong in there, I'm not even going to dignify
this
with a response.
