On Thu, 2005-09-15 at 07:39 -0700, Daniel John Debrunner wrote: > I'm more talking from a functional level. Even with the synchronization > the caller of the method is just seeing a value from the past, no > guarantees over it being the "latest" once the method returns. As soon > as the synchronization is released, ten other threads could execute and > change the value and our original caller already has a stale value > before they operate on it.
The point I was trying to make is that if there are no locks involved at all, and only a single write of a field (as appears to be the case here), a reader might theoretically never see the written value, ever, as the view of memory only passes when the writer threads enters a monitor. So in this context, assuming there were no other monitors entered after the change to the action field, another thread might still see the default value, and take the wrong action. By locking around _something_, (the own object in this case), we at least give other threads a fair chance to see the value we're written by taking any required flush actions to satisfy the memory view model. I agree that if read/write ordering is an issue in the design, locking must be done on a much higher level which covers the event sequencing, but I assume this is already accounted for in the class we're talking about. Regards, Andreas
