db-derby-dev mailing list archives

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

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

Dyre Tjeldvoll commented on DERBY-1704:

cleanup1.diff looks good, but I have a couple of questions:

LockSet has was declared "public final", but is now just "final". Is it intentional?

In general, I have a hard time understanding the multithreading-related comments used in Derby
(not specific to this patch). For example, the comment for LockSet says:
"MT - Mutable - Container Object : Thread Safe". I really don't understand what that means.
Is it still true when LockSet no longer inherits from a synchronized container?

I think what is meant here is that only those methods declared "synchronized" are MT-safe.
A client wanting to use any of the other methods must synchronize on the LockSet object. Correct?

The method addWaiters(Dictionary) is not synchronized, and the comment says "MT - must be
synchronized on this LockSet object". But in Deadock.getWaiters(LockSet) it is called without
synchronization. Presumably this is ok since the old code iterated using an enumeration over
an unlocked LockSet, (unless the lock is higher up the stack, and cannot be seen in the diff).
But a comment would have been nice :)

> 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, split-hashtables.diff,
> 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