Himai Minh wrote:Hi Geoff,
You may consider using ReentrantLock to make a method thread safe.
Stephan van Hulst wrote:... As a more practical tip, use your debugger's stepper. In many IDEs you can switch the currently active thread, and you can step through the code execution for just that one thread. That way, you can try to break your own code by stepping one thread into a critical section of your code when it's not supposed to be there.
Trisha Gee wrote:... Using immutable objects where possible is one way to embrace this approach....
Geoff McKay wrote:This will allow me to see exactly what is going on as the code executes.
How do you decide what won't affect the final result? If you do that simply by having the instructions with disjoint frames, that can add to the trouble. The following three statements have disjoint frames and swapping them can cause problems.
Stephan van Hulst wrote:. . . the processor is free to swap around instructions . . . as long as it doesn't affect the final result . . . .
Stephan van Hulst wrote:... While it's still unlikely that this application will print each phase exactly once, at least it's guaranteed that the phases will no longer be printed out of order. The happens-before relationship in thread A is synchronized with thread B every time they reach synchronized(lock)...
Himai Minh wrote:Hi, Stephen
I think you have been told that incorrectly. Calling assignmnts to primitives in different threads does not establish any “happens‑before” relationship between any of the lines of code.
I heard the happen-before relationship only happen in long or double primitive type. . . .
Campbell Ritchie wrote:How do you decide what won't affect the final result?
If you do that simply by having the instructions with disjoint frames, that can add to the trouble.
Geoff McKay wrote:The happens-before relationship and synchronized(lock) approach would maintain the expected order and looks like a good way. Thanks!
Himai Minh wrote:I heard the happen-before relationship only happen in long or double primitive type.
The frame is the alphabet/“population” of variables acted on by a program; in the case of an assignment it means whatever is left of the = assignment operator. (That will all change if you use ++ or --.) By disjoint I meant that the frames of two programs have no overlap.
Stephan van Hulst wrote:. . . "disjoint frames". . .