It's a test harness and it's purpose is to test the locking mechanism of your Data class and that could be easily done with just 1 iteration. It's all about the update1 and delete1 thread to compete for the lock on record 1. So you certainly have to test that situation. But it even could be that the test runs to completion but still have an issue with your Data class, because the threads ran in a given order and the problem in your code only manifests itself when these threads run in some other order.
So indeed executing 100 times delete1 and update1 is pretty useless, therefor I suggested to add a random delete thread (like the update random thread), but this don't give you the guarantee that 2 threads will compete for the same record (a guarantee which you have with delete1 and update1 threads) and like I already indicated that's a situation you certainly want to test, because that's likely the cause of any issues (of threads not running to completion).
You could also re-use record numbers of deleted entries and then it makes more sense, because the create thread will create a record at position 1 (if the delete1 thread deleted this record already) or at the end of the map (otherwise), so the RNFE will not be thrown that frequently. And I don't know if my good buddy Roberto re-used record numbers of deleted entries, but he shared his test case with the community and you are free to adjust and make changes to this test to make it fit your needs. I re-used record numbers of deleted entries, so I had a whole bunch of thread pairs competing with each other to get a lock on the same record and that helped me to discover an issue in my locking mechanism. If you decided not to re-use these record numbers (it's not a must requirement) you could maybe adjust the code to have a delete and update thread which try to gain the lock of the same record, but not always record 1.
The code used in the test harness is how you are supposed to delete and/or update a record. So it's a 3 step process: lock, update (or delete), unlock. What happens when you just execute this little program (after adjusting it to fit the interface you've got).
Joined: Jul 17, 2011
update thread produce this
And the most important thing: did your program end normally? I guess it did and the output is what you would expect.
Unfortunately this not means that your code is working as expected. Because the delete-thread will be already finished when the update-thread starts, so although you have . Therefore you need to tweak the program a bit: with adding a few Thread.sleep(100); calls you can change the execution of the threads (simulating the thread scheduler).
Can you explain what the adjustments in the program will do? And what's the output of this test run?
Joined: Jul 17, 2011
I still get this out come... you are trying to simulate a wait.. that won't happen in this case too because of RNFE...
i did test if the lock is working by putting a println when it waits and after it wake up using updates only.. and both lines are printed... so I can safely assume it is working if i implemented it completely
Ixus See wrote:I still get this out come... you are trying to simulate a wait.. that won't happen in this case too because of RNFE...
That's indeed the output you want to see. And indeed I'm simulating a wait (both threads want to lock same record, so one of them will go into waiting state). So it's not true that it won't happen because of RNFE. In the scenario I provided the update thread has to wait until the delete thread has finished (or if the update thread was the 1st one to execute, the delete thread has to wait until the delete thread has finished).
If this behavior is not the one you can verify in your implementation, you'll almost certain to fail because you are violating the instructions of the lock-method in the given interface.