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] Updated: (DERBY-2327) Reduce monitor contention in LockSet
Date Fri, 23 Mar 2007 08:41:32 GMT

     [ https://issues.apache.org/jira/browse/DERBY-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Knut Anders Hatlen updated DERBY-2327:

    Attachment: derby-2327-4a.stat

Attaching a new patch (4a) which contains the implementation of a lock
manager which uses ConcurrentHashMap. Before the patch is applied, one
must execute the following command:

  svn cp \
    java/engine/org/apache/derby/impl/services/locks/LockSet.java \

And after the patch is applied:

  svn add java/engine/org/apache/derby/impl/services/locks/ConcurrentPool.java


Description of the patch:

The patch adds two classes
  * ConcurrentLockSet - which is supposed to behave exactly as LockSet,
    only that it uses a ConcurrentHashMap instead of a HashMap.
  * ConcurrentPool - which is like SinglePool only that it creates a
    instance of ConcurrentLockSet instead of LockSet.

ConcurrentLockSet is basically a copy of LockSet that uses
ConcurrentLockSet and replaces all occurrences of

  synchronized (this) { ... }


  try { ... }
  finally { entry.unlock(); }

where entry.lock()/entry.unlock() locks/unlocks a
java.util.concurrent.locks.ReentrantLock associated with each

To avoid Java deadlocks, each thread is normally not allowed to lock
more than one of the ReentrantLocks at a time. The exception is when a
thread performs deadlock detection. To prevent threads running
deadlock detection from running into deadlocks with each other,
different threads cannot run deadlock detection at the same time. A
thread must also release its ReentrantLocks before it starts deadlock
detection, since it might have to wait if another thread is already
running deadlock detection, and if it holds any ReentrantLocks, it
might deadlock with the other deadlock detection thread.

Although the ReentrantLock is released before deadlock detection is
started, we don't want normal lock requests to be able to lock
it. Therefore a flag (actually a java.util.concurrent.locks.Condition
variable) is set to indicate that only threads performing deadlock
detection should be able to lock it. If normal requests try to lock
it, they will see the Condition variable and call await() on it, which
blocks until the thread that started deadlock detection has finished
and reacquired the ReentrantLock.

The new lock manager only works with JDK5 and higher. I made the build
files use the optional jdk16 target, with source and target level set
to 1.5. Is that OK? I thought this was better than requiring yet
another JDK to build Derby.

I have successfully run suites.All and derbyall on Sun's Java 1.4 and
Java 1.6 (1.4 uses SinglePool, 1.6 uses ConcurrentPool). Reviews would
be greatly appreciated. Thanks.

> Reduce monitor contention in LockSet
> ------------------------------------
>                 Key: DERBY-2327
>                 URL: https://issues.apache.org/jira/browse/DERBY-2327
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Performance, Services
>    Affects Versions:
>            Reporter: Knut Anders Hatlen
>         Assigned To: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: ConcurrentHashMap.diff, derby-2327-1a.diff, derby-2327-1a.stat,
derby-2327-2a.diff, derby-2327-2a.stat, derby-2327-3a.diff, derby-2327-4a.diff, derby-2327-4a.stat
> When multiple threads enter the lock manager, only one can access the hash table in LockSet.
To improve scalability on multiple CPUs, it should be possible to have more than one thread
accessing the lock table at the same time.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message