Quantcast

use of read-write locks in IndexAVL

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

use of read-write locks in IndexAVL

Max Schaefer-2
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?

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.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: use of read-write locks in IndexAVL

Fred Toussi-2
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"
<[hidden email]> 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 [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
Loading...