db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Fredriksson <andreas.fredriks...@digitalroute.com>
Subject Re: Class loading deadlock
Date Thu, 15 Sep 2005 14:52:21 GMT
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

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


View raw message