db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-1704) Allow more concurrency in the lock manager
Date Mon, 22 Jan 2007 14:36:30 GMT

    [ https://issues.apache.org/jira/browse/DERBY-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466466

Knut Anders Hatlen commented on DERBY-1704:

I have attached v2 of cleanup1. I went through LockSet's methods to determine which of them
were not thread safe without extra synchronization and updated their javadoc comments. Changes
from the first version:

* MT comment for LockSet class changed to "MT - Mutable - Container Object : All non-private
methods of this class are thread safe unless otherwise stated by their javadoc comments."

* Added javadoc comments to LockSet.oneMoreWaiter() and LockSet.oneLessWaiter() with information
about required synchronization.

* Removed what seems to be a false comment in LockSet.anyoneBlocked() ("no synchronization
needed because reads of ints are atomic"). It is true that reads of ints are atomic, but synchronization
is still needed to avoid that an old cached value is read instead of the real value.

* Declared LockSet.anyoneBlocked() as synchronized to avoid the problem mentioned above. Currently,
I don't think it is a problem since all calls to anyoneBlocked() come (indirectly) from the
unit tests T_AccessFactory and T_LockFactory, but it would be good to fix it anyway.

* Added javadoc and MT comment to Deadlock.look().

I have started a new run of derbyall.

> Allow more concurrency in the lock manager
> ------------------------------------------
>                 Key: DERBY-1704
>                 URL: https://issues.apache.org/jira/browse/DERBY-1704
>             Project: Derby
>          Issue Type: Improvement
>          Components: Performance, Services
>    Affects Versions:
>            Reporter: Knut Anders Hatlen
>         Assigned To: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: 1cpu.png, 2cpu.png, 8cpu.png, cleanup1.diff, cleanup1.stat, cleanup1.v2.diff,
split-hashtables.diff, split-hashtables.stat
> I have seen indications of severe monitor contention in SinglePool
> (the current lock manager) when multiple threads access a Derby
> database concurrently. When a thread wants to lock an object, it needs
> to obtain the monitor for both SinglePool and LockSet (both of them
> are global synchronization points). This leads to poor scalability.
> We should investigate how to allow more concurrency in the lock
> manager, and either extend SinglePool or implement a new manager.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message