Thanks for the review.
Answers inline.
Please ask any further question, and if possible, provide a note of the
results. Independent code reviews are invaluable and welcome.
Fred Toussi
On Tue, 10 Aug 2010 18:11 +0100, "Max Schaefer"
<max.schae...@comlab.ox.ac.uk> wrote:
> Hi list,
>
> I am currently involved in a research project where we are looking at
> uses of the java.util.concurrent.locks library in real-world code.
> Hsqldb caught our eye as one of the few large programs to make use of
> these locks, in particular ReadWriteLocks.
>
> I am trying to get an understanding of the use of read locks vs. write
> locks in class org.hsqldb.index.IndexAVL, and I have noted some
> peculiarities that I would appreciate anybody shedding some light on.
>
> In method size(Session, PersistentStore), for instance, the method
> body is protected by a read lock. Now all that method does is to
> invoke PersistentStore.elementCount(Session) on its argument
> "session". If that argument should have runtime type RowStoreAVLDisk,
> this invocation will dispatch to RowStoreAVLDisk's implementation of
> that method, which reads and writes the field "elementCount" without
> further synchronisation, potentially leading to a race condition.
>
> My question is: can this actually happen? Is method size just never
> invoked with an argument of that type? Or is it never invoked from
> more than one thread concurrently?
Given that more than one thread can share a read lock, "elementCount"
can be -1 to multiple threads. Each thread would then call
getNodeCount(session, this) with identical results and the result
assigned to elementCount. Identical because no write can take place
while read locks are held. (In practice -1 can exist only during the
initialisation of the database, when only a single thread is active).
>
> In a similar manner, methods isEmpty(PersistentStore),
> checkIndex(PersistentStore), firstRow, lastRow, and findNode invoke
> IndexAVL.getAccessor, which in turn (given the right dynamic types)
> could invoke RowStoreAVLDisk.getAcessor; that method reads and writes
> the array accessorList without further synchronisation.
>
Multiple threads can enter the block of code here which writes a NodeAVL
"node" to an element of accessorList.
if (!node.isInMemory()) {
RowAVL row = (RowAVL) get(node.getPos(), false);
node =
row.getNode(key.getPosition());
accessorList[key.getPosition()] = node;
}
The assigned "node" objects may be different objects, but they are
"equal" objects due to the read lock blocking the write lock. The
purpose of this assignment is to purge any stale node with not-up-to-
date children.
> Thanks in advance for your help, -- Max Schaefer
>
>
> ----------------------------------------------------------------------
> --------
> This SF.net email is sponsored by
>
> Make an app they can't live without Enter the BlackBerry Developer
> Challenge http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> hsqldb-developers mailing list hsqldb-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
>
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
hsqldb-developers mailing list
hsqldb-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
