Abstract: In the previous newsletter, we sent out a threading puzzle for you to solve. Here are some hints to help you figure out what is going on.
A big thank you to all those who already emailed me their solution to last week's puzzle. Most of the answers were correct in theory, but wrong in practice :-) It is in my experience better to learn by doing, rather than watching someone else. So you will get more benefits from attempting to solve it than from reading my solution. So if you have not tried yet or if you got stuck in your efforts, here are some helpful hints:
1. We can argue correctness by using the Java Memory Model (JMM). However, most of the concurrency bugs that you can get with happens-before, early writes, visibility, etc. are very hard to reproduce. We certainly would find a hard time writing a test that fails with such consistency as this one. That's the first hint.
2. Second hint is to never believe what your customers are telling you is the problem. The explanation with System.arraycopy() is clearly a "red herring". To be fair, Jack did send it to me as a possible explanation. However, I didn't look at the code of System.arraycopy() as I didn't really believe the reason for the failure would be found there. So you can ignore System.arraycopy(). You can verify that even if you start with a larger array of 1000, it still fails.
3. Whenever we try to solve concurrency bugs, we have to be able to reproduce the error first. This might mean looking for other hardware that exhibits the problem (that's what I did). Once you see it happening, change the code a bit at a time and see if it still occurs.
4. Last hint. The solution to this puzzle is unbelievably simple. Really, any Java programmer can solve it, not just the concurrency elite. There is one side effect that is forbidden in Swift 3 and which causes the race condition. 'nough hints ;-)
I also suggested that you use StampedLock to code this correctly. Admittedly that is a bit more difficult than solving the puzzle. StampedLock contains three idioms in the JavaDoc comments that you can use as a basis for add(), remove() and get(). Once you have done it, please email it to me and you'll get an opportunity to contribute to our solution and get your name in the credits.
We deliver relevant courses, by top Java developers to produce more resourceful and efficient programmers within their organisations.
Nobody ever wants to call a Java performance consultant, but with first-hand experience repairing and improving commercial Java applications - JavaSpecialists are a good place to start...