5 ms·
Without looking at it too closely, there's no synchronization on the point. The synchronized this (with an empty block - wtf -- that's meaningless) has nothing
by methehack 13y ago
Without looking at it too closely, there's no synchronization on the point. The synchronized this (with an empty block - wtf -- that's meaningless) has nothing to do with the point...so the point is possibly stale. I haven't assessed the logic more than that to see if that's a possible state that would program exit, but it's the first thing I noticed. Also, this program, as others have pointed out, is weirdly complex -- and that's a euphemism.
- a-priori 13y agoI don't believe the synchronized(this){} block is entirely meaningless. Essentially it acts as a gate where execution will halt until all other synchronized(this) blocks are complete before continuing. That's not to say another concurrent access can't sneak in between the block and the next statement, of course, but it does change the behaviour somewhat. But I can't really think of a use case. As a side effect, it may also act as a memory barrier.
- conroe64 13y agoI think the logic is more to elicit a strange occurrence (bug, dare I say?) that doesn't occur unless under some weird circumstances. In this case, this behavior would be possible unless the value of a variable, currentPos, is set to an object before that object's constructor finished, and all in the same thread! The only possible explanation is that the JIT decided to reorder the execution so the variable was set to memory allocated for the object, and then ran the objects constructor. It's all very surprising behavior.