Patricia Shanahan wrote:
On 12/3/2010 7:15 AM, Gregg Wonderly wrote:
...
> The important issue in FastList is that it was written with the JDK1.4
> memory model. After moving River to Java 1.5, we'd have the JSR166 work
> and the new, consistent memory model where volatile has a true meaning.
> However, this code in particular is quite complex as you have noted, so
> even adjusting to the new memory model could be problematic.
I've just run a modified, simplified version of my test with java
version "1.4.2_19" and an unmodified copy of FastList, and I still get
the NullPointerException. This changes my thinking a bit. I had been
working from the assumption that the issue was to do with the changes
in memory model between 1.4 and 1.5. I now have to consider the
possibility of a more basic bug that is independent of the memory model.
If there is anyone with a FastList or Java memory model background who
would like to help, please reply. I would welcome another set of eyes
on the code, and a cross check on my conclusions so far about how
FastList is supposed to work. There seems to be a critical invariant
that gets broken, and once that happens we are on track to either a
NullPointerException or dropped items.
I can supply my test as a unit test (JDK 1.6, Junit 4) and as a main
program (JDK 1.4 or later0. In both forms, all it does is fire up a
mixture of threads that repeatedly add items to a FastList and threads
that repeatedly remove the first item they can from the FastList.
Failures seem to require simultaneous adds and removes.
If I don't nail this problem fairly soon, I may abandon the current,
rather complicated, code and switch to writing a concurrent high
performance FastList substitute for 1.5 or later.
Patricia
I'll have a look tonight, no promises though ;)
Cheers,
Peter.
