Comments on: Immutable Trees and Threading Evil – Part 2

By: David

David — Thu, 24 Jan 2008 19:27:24 +0000

I don’t know know enough about Java to comment on your post from that perspective. However, since the post was inspired from another post about .NET, I thought I would point out that what you described is impossible in .NET. Your scenario relies on the fact that once the memory for an object has been allocated, other objects can reference that object, even if it has not been constructed yet. In .NET this is not possible. There can never be an optimization such that an object is referenced before it is fully constructed. So this would never be a problem, and Eric’s original statement on his blog post holds.

By: Brian McKeever

Brian McKeever — Thu, 20 Dec 2007 07:10:46 +0000

I agree that modifying shared resources without locking can lead to trouble. But what I was getting at was that if the instruction reordering you suggested were allowed, then the problem would be visible from within a single thread (if put and take used the same index). Right?

And as you say, the model doesn’t allow this, so it follows that the instruction reordering is not allowed. That was the contradiction I was trying to point out.

By: mcherm

mcherm — Thu, 20 Dec 2007 02:21:19 +0000

Brian:

(1) No, it couldn’t happen with a single thread, because the Java Memory Model (which governs what kind of reordering the compiler can do) specifically states that any re-orderings must not be visible to the SAME thread, but allows them to be visible to OTHER threads.

(2) Whether it’s one line or multiple lines doesn’t change things at all. In the end, the compiler is optimizing pretty much the same code. (All optimizing compilers are smart enough to realize when a variable can’t be seen outside of the method.)

(3) I’m not quite sure what you mean by “strict order of evaluation”.

(4) No, my code never printed that. I have two reasons for that. First, I’m not using both processors (when running it uses only 50% CPU) and these things won’t typically show up when running in time slices on one CPU because the crucial “two things happening at about the same time” isn’t occurring. Secondly, this example isn’t particularly realistic: the optimization I describe is *allowed* but is probably not *sensible* in this case. But similar (and equally puzzling) things DO occur in real programs.

By: Brian McKeever

Brian McKeever — Thu, 20 Dec 2007 01:19:39 +0000

If your explanation were correct, you don’t need multiple threads to encounter the problem, do you? Your “other possible ordering” with just a single thread could result in a node being its own parent (if one of the gets uses the same index as the put), right?

Supposing you rewrote the code to be a single statement:
nodePool.putNode(new TreeNode(nodePool.takeRandomNode(), nodePool.takeRandomNode()));

How would you reconcile the possibility of cyclic trees with the strict order of evaluation that Java applies to its statements?

Did your code ever print “We Found A Loop!!”?