[
https://issues.apache.org/jira/browse/AURORA-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14163663#comment-14163663
]
Bill Farner commented on AURORA-800:
------------------------------------
Not a blocker, but one potential gotcha:
{quote}
While ReadWriteLock instances have different properties and can form cycles
without potential deadlock, this class treats ReadWriteLock instances as
equivalent to traditional exclusive locks. Although this increases the false
positives that the locks detect (i.e. cycles that will not actually result in
deadlock), it simplifies the algorithm and implementation considerably. The
assumption is that a user of this factory wishes to eliminate any cyclic
acquisition ordering.
{quote}
Even if we are vulnerable to this, there's no reason we can't use the factory
for everything but the storage lock (the only ReadWriteLock we use) for now.
> consider using Guava's CycleDetectingLockFactory
> ------------------------------------------------
>
> Key: AURORA-800
> URL: https://issues.apache.org/jira/browse/AURORA-800
> Project: Aurora
> Issue Type: Story
> Components: Reliability, Scheduler
> Reporter: Kevin Sweeney
> Priority: Critical
>
> Occasional scheduler deadlock bugs would have benefited from proactive
> detection. Guava provides a utility class,
> [CycleDetectingLockFactory|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/util/concurrent/CycleDetectingLockFactory.html],
> which is well-suited to this task.
> Keeping with our general practice of leaving all assertions enabled at
> runtime unless data suggests performance is impacted, I propose replacing
> almost all usage of the {{synchronized}} keyword or a
> {{ReentrantReadWriteLock}} with a {{CycleDetectingLockFactory}}-managed
> variant unless we have data to suggest performance would be adversely
> impacted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
