d2e3d4c6f1
## Issue Addressed Mitigates #1096 ## Proposed Changes Add a flag to the beacon node called `--disable-lock-timeouts` which allows opting out of lock timeouts. The lock timeouts serve a dual purpose: 1. They prevent any single operation from hogging the lock for too long. When a timeout occurs it logs a nasty error which indicates that there's suboptimal lock use occurring, which we can then act on. 2. They allow deadlock detection. We're fairly sure there are no deadlocks left in Lighthouse anymore but the timeout locks offer a safeguard against that. However, timeouts on locks are not without downsides: They allow for the possibility of livelock, particularly on slower hardware. If lock timeouts keep failing spuriously the node can be prevented from making any progress, even if it would be able to make progress slowly without the timeout. One particularly concerning scenario which could occur would be if a DoS attack succeeded in slowing block signature verification times across the network, and all Lighthouse nodes got livelocked because they timed out repeatedly. This could also occur on just a subset of nodes (e.g. dual core VPSs or Raspberri Pis). By making the behaviour runtime configurable this PR allows us to choose the behaviour we want depending on circumstance. I suspect that long term we could make the timeout-free approach the default (#2381 moves in this direction) and just enable the timeouts on our testnet nodes for debugging purposes. This PR conservatively leaves the default as-is so we can gain some more experience before switching the default.
49 lines
1.6 KiB
Rust
49 lines
1.6 KiB
Rust
use parking_lot::{RwLock, RwLockReadGuard, RwLockWriteGuard};
|
|
use std::sync::atomic::{AtomicBool, Ordering};
|
|
use std::time::Duration;
|
|
|
|
/// A simple wrapper around `parking_lot::RwLock` that only permits read/write access with a
|
|
/// time-out (i.e., no indefinitely-blocking operations).
|
|
///
|
|
/// Timeouts can be optionally be disabled at runtime for all instances of this type by calling
|
|
/// `TimeoutRwLock::disable_timeouts()`.
|
|
pub struct TimeoutRwLock<T>(RwLock<T>);
|
|
|
|
const TIMEOUT_LOCKS_ENABLED_DEFAULT: bool = true;
|
|
static TIMEOUT_LOCKS_ENABLED: AtomicBool = AtomicBool::new(TIMEOUT_LOCKS_ENABLED_DEFAULT);
|
|
|
|
impl TimeoutRwLock<()> {
|
|
pub fn disable_timeouts() {
|
|
// Use the strongest `SeqCst` ordering for the write, as it should only happen once.
|
|
TIMEOUT_LOCKS_ENABLED.store(false, Ordering::SeqCst);
|
|
}
|
|
}
|
|
|
|
impl<T> TimeoutRwLock<T> {
|
|
pub fn new(inner: T) -> Self {
|
|
Self(RwLock::new(inner))
|
|
}
|
|
|
|
fn timeouts_enabled() -> bool {
|
|
// Use relaxed ordering as it's OK for a few locks to run with timeouts "accidentally",
|
|
// and we want the atomic check to be as fast as possible.
|
|
TIMEOUT_LOCKS_ENABLED.load(Ordering::Relaxed)
|
|
}
|
|
|
|
pub fn try_read_for(&self, timeout: Duration) -> Option<RwLockReadGuard<T>> {
|
|
if Self::timeouts_enabled() {
|
|
self.0.try_read_for(timeout)
|
|
} else {
|
|
Some(self.0.read())
|
|
}
|
|
}
|
|
|
|
pub fn try_write_for(&self, timeout: Duration) -> Option<RwLockWriteGuard<T>> {
|
|
if Self::timeouts_enabled() {
|
|
self.0.try_write_for(timeout)
|
|
} else {
|
|
Some(self.0.write())
|
|
}
|
|
}
|
|
}
|