From be7d7d95850c30a154aaa56e95d6a7f36793409d Mon Sep 17 00:00:00 2001
From: Simon Rettberg
Date: Wed, 7 Aug 2019 17:11:51 +0200
Subject: [SERVER] Better lock debugging: Always check lock order

Lock order is predefined in locks.h. Immediately bail out if a lock with
lower priority is obtained while the same thread already holds one with
higher priority.
---
 LOCKS | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

(limited to 'LOCKS')

diff --git a/LOCKS b/LOCKS
index 4b5b07c..77e44a8 100644
--- a/LOCKS
+++ b/LOCKS
@@ -16,23 +16,22 @@ requests.lock
 
 ===== SERVER =====
 This is a list of used locks, in the order they
-have to be aquired if you must hold multiple locks:
-remoteCloneLock | reloadLock
+have to be aquired if you must hold multiple locks.
+Note this list might be out of date, take a look at the
+defines in lock.h for the effective order.
+reloadLock
+remoteCloneLock
 _clients_lock
 _clients[].lock
 integrityQueueLock
 _images_lock
 _images[].lock
-pendingLockConsume
-pendingLockProduce
 uplink.queueLock
 altServersLock
 client.sendMutex
-client.statsLock
-statisticsSentLock
-statisticsReceivedLock
 uplink.rttLock
 uplink.sendMutex
+aclLock
 
 If you need to lock multiple clients/images/... at once,
 lock the client with the lowest array index first.
-- 
cgit v1.2.3-55-g7522