I'll try. I really think there are three strategies that should be
considered separately:
1. Fix concurrency bugs in River code, even if the bug can only be
identified in theory, without causing any known external symptoms.
2. Externalize some or all of any facilities that are added to implement
Strategy 1, so that users can apply them in their own code.
3. Log non-use of Strategy 2 facilities in order to encourage users to
use them.
I'm going to use Startable as an example to illustrate the differences
between these strategies.
Adding Startable to a River implementation package, and using it in
River code, is a Strategy 1 item. It would not call for a separate vote,
but would be voted on as part of a release candidate that implements
Strategy 1.
Putting Startable in a package users are expected to use directly,
documenting it as part of River's external interface, is a Strategy 2
item. It is an external interface change, and needs to be voted on
accordingly.
Logging non-use of Startable is a Strategy 3 item, and is also an
external interface change.
Patricia
On 12/21/2013 3:11 AM, Peter wrote:
Yes it's a difficult decision, originally when I set out to fix the issues I
found, I didn't expect to be here today, on one hand, I'd like to complete the
work I started, I've invested too much time to walk away now.
On the other hand, "The community" may not want it fixed.
Patricia, you're much better at communicating the development concepts, can you
do me a favour and put forward a vote proposal, it would be beneficial to all
parties to come to some decision on the underlying issue.
Regards,
Peter.
----- Original message -----
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.
