I am trying to create and see a race condition by running a very common double checked locking code. Instead I am seeing a NullPointerException at the bold line underneath, which I don't want to.
I am running the above code say some 2000 times from a for loop, but have been unfortunate so far to see a hashcode value of a partially constructed object. I am running it on java 6. If I can predict that what is going to happen, the whole importance of threading is lost. But just for the heck of it, I want to see a race condition as I mentioned above. Need help!!!
The first time you're calling getResource(), resource will be null and then you're calling the hashCode() on that null reference causing the NullPointerException.
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler
Please correct my English.
Joined: Apr 23, 2006
Thanks for your reply. But that's precisely my question. I am expecting that when say Thread 2 reaches that sysout line, the resource should have an address reference of a partially constructed object by Thread 1. I am trying just to reecreate it. It may happen one in 10000 times but so far I am unlucky to see that.
Do you have any other code snippet where the probability of seeing a partially constructed object is more ?
I really see why you would want this. There are a lot of examples out there about why you should properly synchronize e.g. a banking example.
Line 19 will always throw a NullPointerException since you have a lock on this and resources is null. Also "before" should be "in".
It may happen one in 10000 times but so far I am unlucky to see that.
It may happen never ;-)
The JVM is allowed to do this to you, doesn't mean it will, the list of variables is quite large (CPU, OS, JVM version, OS load) .. you've probably got no chance of reproducing it (doesn't mean its not there) even the process of debugging / logging is affecting your ability to find it. You could try throwing IBM's contest or playing with terracota if its purely to get round your head round the issue.
A challenge for the unittest gurus out there ... unit test this ... (I'm suggesting you can't .. love to be proved wrong ;-) , I've actually seen unit test code with these bugs sort of bugs in them)
"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
I have also tried to reproduce it. I used the eclipse embedded debugger to perform the precise actions needed to replicate the bug with no success. I think that certain java compilers could(in theory) do this however I am sure the compiler I use waits for the variable to be fully created before passing the memory reference to the variable.
Your waking an old thread they don't tend to like that .
.. but its not just your compiler , its the CPU, OS etc etc you have no memory barrier (the compiler is not the only potential issue), its possible the byte code will run every time correctly but if the JVM where to change or you moved the code to a different machine it may fail i.e. its no longer portable.