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 Wed, 14 Sep 2005 16:18:30 GMT
Andreas Fredriksson wrote:

> On Wed, 2005-09-14 at 08:51 +0200, Andreas Fredriksson wrote:
> 
> 
>>I think the only fix is to rewrite the class definition code in Derby to
>>avoid taking a lock on the helper objects, but I don't know the source
>>code well enough to write a proper fix.
> 
> 
> Maybe I should spend more time tweaking before sending email in the
> future.. :-)
> 
> The attached patch fixes the problem for me. I'm sure there's more than
> this to it, but please feel free to use this a reference. We'll use it
> locally and see if anything else creeps up.

Thanks for the patch, it may provide the correct approach but from a
quick look the patch has some incorrect synchronization.

For example, this extract.

> +		synchronized (this) {
> +			action = 2;
> +		}

Synchronizing a single atomic action typically makes no sense, because
as soon as the synchronization is released the state can change, in this
case action could be modified. Synchronization involves ensuring
*multiple* atomic actions occur in lock step, not a single atomic action.
In this case the setting of the action variable needs to be synchronized
with the priv block call, otherwise another thread could change action
and thus change the behaviour of the call that the original thread was
expecting.

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.

Dan.


Mime
View raw message