aurora-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Farner (JIRA)" <>
Subject [jira] [Commented] (AURORA-800) consider using Guava's CycleDetectingLockFactory
Date Wed, 08 Oct 2014 16:09:34 GMT


Bill Farner commented on AURORA-800:

Not a blocker, but one potential gotcha:
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.

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:
>             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|],
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

View raw message