if the code specified is not synchronized, then it is feasible that, at a particular point in time in the view of another thread, y == 20 but x != 10.
The reason, as explained in Java Concurrency in Practice (*), is "reordering" -- the JVM is allowed to reorder the operations of instructions so long as the changes are not detectable in the current thread. However, the changes may well be detectable in other threads (without proper synchronization).
Pretty wild stuff.... This book has led me to define my "3 laws of concurrency", which essentially state that if you don't understand threading issues, you will have bugs. And if you do understand threading issues, you'll have bugs.
In the original code snippet, it looks like x, y, z are local variables. In which case each thread has its own stack, with its own local variables, and no way to observe out-of-order behavior in other threads' data. Whereas if x, y, z were instance variables, then different threads could be accessing the same data, leading to the behavior you describe in your second post.
I agree that multiple threads can create some very bizarre effects, tough to wrap the brain around. [ May 06, 2007: Message edited by: Jim Yingst ]
"I'm not back." - Bill Harding, Twister
Joined: Feb 11, 2007
Oops! Excellent point, Jim...
that's what I get for not wanting to plagarize an example from the book :roll:
I will edit the original post but major kudos for catching this