+
+Job Queue Locking
+-----------------
+
+The job queue is designed to be thread-safe. This means that its public
+functions can be called from any thread. The job queue can be called from
+functions called by the queue itself (e.g. logical units), but special
+attention must be paid not to create deadlocks or an invalid state.
+
+The single queue lock is used from all classes involved in the queue handling.
+During development we tried to split locks, but deemed it to be too dangerous
+and difficult at the time. Job queue functions acquiring the lock can be safely
+called from all the rest of the code, as the lock is released before leaving
+the job queue again. Unlocked functions should only be called from job queue
+related classes (e.g. in jqueue.py) and the lock must be acquired beforehand.
+
+In the job queue worker (``_JobQueueWorker``), the lock must be released before
+calling the LU processor. Otherwise a deadlock can occur when log messages are
+added to opcode results.
+
+
+Node Daemon Locking
+-------------------
+
+The node daemon contains a lock for the job queue. In order to avoid conflicts
+and/or corruption when an eventual master daemon or another node daemon is
+running, it must be held for all job queue operations
+
+There's one special case for the node daemon running on the master node. If
+grabbing the lock in exclusive fails on startup, the code assumes all checks
+have been done by the process keeping the lock.