summaryrefslogtreecommitdiffstats
path: root/LOCKS
diff options
context:
space:
mode:
authorManuel Bentele2020-10-22 12:08:34 +0200
committerManuel Bentele2020-10-22 12:08:34 +0200
commitf9872723efc831827d179c3baf5b9f6c428512c4 (patch)
tree9662cc3071362570a1f4051f0850b41fbdfff246 /LOCKS
parent[BUILD] add option to build the dnbd3-server with afl-fuzz support (diff)
downloaddnbd3-f9872723efc831827d179c3baf5b9f6c428512c4.tar.gz
dnbd3-f9872723efc831827d179c3baf5b9f6c428512c4.tar.xz
dnbd3-f9872723efc831827d179c3baf5b9f6c428512c4.zip
[BUILD] add CMake targets to build binary and source packages with CPack
This patch adds the following CMake targets - package - source to build bundeled packages. Those packages contain either all built binary artifacts or all source files for source code distribution. Both CMake targets are available in Release build configuration.
Diffstat (limited to 'LOCKS')
-rw-r--r--LOCKS80
1 files changed, 0 insertions, 80 deletions
diff --git a/LOCKS b/LOCKS
deleted file mode 100644
index 77e44a8..0000000
--- a/LOCKS
+++ /dev/null
@@ -1,80 +0,0 @@
-Some notes about locking in dnbd3
-
-The order of aquiring multiple locks is
-VERY IMPORTANT, as you'll produce a possible deadlock
-if you do it in the wrong order.
-Take very good care of locking order if you have lots
-of functions that call each other. You might lose
-track of what's going on. ;)
-
-===== FUSE =====
-mutexInit
-newAltLock
-altLock
-connection.sendMutex
-requests.lock
-
-===== SERVER =====
-This is a list of used locks, in the order they
-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
-uplink.queueLock
-altServersLock
-client.sendMutex
-uplink.rttLock
-uplink.sendMutex
-aclLock
-
-If you need to lock multiple clients/images/... at once,
-lock the client with the lowest array index first.
-
-If the program logic would require to aquire the
-locks in a different order, you HAVE TO rework the
-code.
-For example, if you hold the lock for client 10 and
-you need to look up some other client. You MUST NOT
-simply fetch the _clients_lock now and then iterate
-over the clients until you find the one you need,
-as it violates the above order to first lock on the
-clients array and then the clients lock.
-Instead, you need to release client 10's lock,
-then lock on _clients_lock and iterate over the
-clients. Now you check if you either encounter
-the client you originally held the lock on, or
-the client you are looking for. You immediately
-lock on those two. You can then release the
-_clients_lock and work with both clients.
-pseudo code:
-
-// client10 is assumed to be a pointer to
-// a client, which happens to be at index 10
-lock (client10->lock);
-....
-// oh, i need another client
-unlock(client10->lock);
-lock(_clients_lock);
-client clientA = NULL, clientB = NULL;
-for (i = 0; i < _num_clients; ++i) {
- if (client[i] == client10) {
- clientA = client[i];
- lock(clientA.lock);
- } else if (client[i].something == <whatever>) {
- clientB = client[i];
- lock(clientB.lock);
- }
-}
-unlock(_clients_lock);
-if (clientA && clientB) { // Make sure we actually found both!
- // DO something important with both clients
-}
-if (clientA) unlock(clientA.lock);
-if (clientB) unlock(clientB.lock);
-