On 2/13/2011 8:16 AM, Dan Creswell wrote:
....
On 13 February 2011 12:31, Patricia Shanahan<[email protected]> wrote:
Thanks for looking at the code.
No worries - concurrency is a favourite topic of mine :)
Excellent. Perhaps you could also review my substitute FastList
implementation. It is in my skunk/patsOutrigger repository,
src/com/sun/jini/outrigger/FastList.java
I believe reliable concurrency is best achieved by defense-in-depth,
including careful coding, testing, and code review by at least one
concurrency expert other than the author. Obviously, the most important
objective is to find any bugs in it, but I am also interested in
suggestions for improvement.
I have just reproduced the FastListTest non-termination on WindowsXP:
$ java -version
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
We definitely have a bug in the old FastList. I suspect that the QA test
has some bottleneck, possibly in the communication between the test job
and the outrigger server job, that protects FastList from the
combination that triggers its bug or bugs.
Alarmingly, an overnight repeated run of the QA test did not get any
FastList failures, but did get an unrelated NullPointerException from proxy
code called from the test program.
Mmmm, well that might be indicative of a separate problem. However, in
respect of the Fast List issue, it's not unusual for a concurrency problem
such as this (likely a race condition) to not manifest consistently so....
I think the best course of action is a few hours of the QA test with the
new FastList. That is something I should do anyway. If the new
NullPointerException reproduces I'll investigate it, if not I'll ignore
it on the assumption that it is a side-effect of the FastList issues.
Patricia
