db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Class loading deadlock
Date Thu, 15 Sep 2005 14:39:17 GMT
Andreas Fredriksson wrote:
> On Wed, 2005-09-14 at 09:18 -0700, Daniel John Debrunner wrote:
> 

>>As another general example, if I ever see code like this I know the
>>coder maybe unclear on synchronization.
>>
>>public synchronized int getCount()
>>{
>>     return count;
>>}
>>
>>The synchronization here doesn't guarantee anything, as soon as the
>>method returns the count could change so the caller is only ever seeing
>>a snapshot of the state, which is exactly what would happen if the
>>method was not synchronized.
> 
> 
> Yes, but see the above note. You're not guaranteed to see the _latest_
> value written to that field, as per the Java Memory Model. If you
> synchronize, you explicitly request to see the most recently visible
> memory in that field, as flushed by other threads taking a lock.

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.

If the caller wants to guarantee the latest value and perform some other
action based upon the guaranteed latest value then the synchronization
needs to cover reading the value and the action. This of course is the
common case.

Thus I see such a synchronized single action method as a red-flag
because there's a good chance the coder thought that this simple
synchronization solved some other issue.

> Sorry for the lengthy bantering :-)

No need to apologize, it's good to see various points of view &
discussions etc.

Dan.



Mime
View raw message