Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Date: Thu, 21 Dec 2006 10:34:51 +0100
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: A question about some synchronized code
In-reply-to: <BAY23-F204DE1985C7EA1021CA8329ACF0@phx.gbl>
Sender: Knut.Hatlen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <wjo84prp618k.fsf@sun.com>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <BAY23-F204DE1985C7EA1021CA8329ACF0@phx.gbl>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.91 (usg-unix-v)

Raymond Raymond <raymond_derby@hotmail.com> writes:

> Today, when I read the source code of
> org.apache.derby.impl.store.raw.data.CachedPage.java,
> I found some synchronized code like:
>
> public boolean isDirty()    {
>   synchronized (this)  {
>       return isDirty || preDirty;
>   }
> }
>
> public boolean isActuallyDirty() {
>   synchronized (this) {
>       return isDirty;
>   }
> }
>
> I have two questions about them, hope someone can answer me:
> 1. Is it necessary to synchronize the code in these places?

There must be some kind of synchronization since the isDirty and
preDirty flags can be accessed and modified by multiple threads, but
it could probably be done on a higher level. Many of the callers of
these methods are already synchronized on the page object, and in
those cases the synchronization is not needed. There does however seem
to be callers that don't synchronize too.

Note that the javadoc for Cacheable.isDirty() says "MT - thread
safe". Removing the synchronization in CachedPage.isDirty() would
break that contract.

> 2. I saw someone else commented on some code (in derby) said it's
> not good to return from inside of a synchronized block. What
> potential problem it will cause if return from inside of a
> synchronized block?

I'm not sure what problems that could be. When returning from a
synchronized block, the monitor is released (unless the thread already
owned the monitor when it entered the synchronized block). Do you have
a pointer to that discussion?

-- 
Knut Anders