f - lock order docs cleanup

Author: ViktorTigerstrom

lightning/src/ln/channelmanager.rs

@@ -698,8 +698,8 @@ pub struct ChannelManager<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref,
 	/// here are failed when we process them as pending-forwardable-HTLCs, and entries are removed
 	/// after we generate a PaymentReceived upon receipt of all MPP parts or when they time out.
 	///
-	/// If any of these locks are held at the same time as `pending_inbound_payments`, the lock
-	/// order requires that these locks are taken prior to `pending_inbound_payments`:
+	/// If any of these locks are held at the same time, they must be acquired prior and in the
+	/// following order:
 	/// * `channel_state`
 	/// * `forward_htlcs`
 	/// * `per_peer_state`
@@ -716,8 +716,8 @@ pub struct ChannelManager<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref,
 	///
 	/// See `PendingOutboundPayment` documentation for more info.
 	///
-	/// If any of these locks are held at the same time as `pending_outbound_payments`, the lock
-	/// order requires that these locks are taken prior to `pending_outbound_payments`:
+	/// If any of these locks are held at the same time as, they must be acquired prior and in the
+	/// following order:
 	/// * `channel_state`
 	/// * `forward_htlcs`
 	/// * `per_peer_state`
@@ -733,7 +733,7 @@ pub struct ChannelManager<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref,
 	/// Note that no consistency guarantees are made about the existence of a channel with the
 	/// `short_channel_id` here, nor the `short_channel_id` in the `PendingHTLCInfo`!
 	///
-	/// If also holding `channel_state` lock, must lock `channel_state` prior to `forward_htlcs`.
+	/// Locked *after* `channel_state`.
 	#[cfg(test)]
 	pub(super) forward_htlcs: Mutex<HashMap<u64, Vec<HTLCForwardInfo>>>,
 	#[cfg(not(test))]
@@ -799,22 +799,22 @@ pub struct ChannelManager<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref,
 	/// operate on the inner value freely. Sadly, this prevents parallel operation when opening a
 	/// new channel.
 	///
-	/// If any of these locks are held at the same time as `per_peer_state`, the lock order
-	/// requires that these locks are taken prior to `per_peer_state`:
+	/// If any of these locks are held at the same time, they must be acquired prior and in the
+	/// following order:
 	/// * `channel_state`
 	/// * `forward_htlcs`
 	per_peer_state: RwLock<HashMap<PublicKey, Mutex<PeerState>>>,
 
-	/// If any of these locks are held at the same time as `pending_events`, the lock order
-	/// requires that these locks are taken prior to `pending_events`:
+	/// If any of these locks are held at the same time, they must be acquired prior and in the
+	/// following order:
 	/// * `channel_state`
 	/// * `forward_htlcs`
 	/// * `per_peer_state`
 	/// * `pending_inbound_payments`
 	/// * `pending_outbound_payments`
 	pending_events: Mutex<Vec<events::Event>>,
-	/// If any of these locks are held at the same time as `pending_background_events`, the lock
-	/// order requires that these locks are taken prior to `pending_background_events`:
+	/// If any of these locks are held at the same time, they must be acquired prior and in the
+	/// following order:
 	/// * `channel_state`
 	/// * `forward_htlcs`
 	/// * `per_peer_state`