[
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: 10.2.1.6
> 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
