Dear C++ ISO standardization comity and fellow community members,

Please allow me to make a proposal for your consideration of a deadlock detecting guarding mechanism.
Please refer to the repository inlinestatic/Scheduler: Threadpool with Deadlock detection (github.com)<https://github.com/inlinestatic/Scheduler>
Guard.h and Guard.cpp files containing the implementation of cascade_mutex.
Job.h and Job.cpp serves as simple applicability example of schedule-driven architecture where thread and resource orchestration may be necessary. main.cpp program deliberately produces exceptions to demonstrate successful detection.

Problem - Vastly multithreaded single process running many threads that share common resources sometimes can be poorly synchronized. By looking at the system from a perspective of a number of threads prevalent in the program multiplied by every step in a call tree for a specific tread it can be imagined as a system with a nondeterministic number of states. Some threads may require the safe sharing of nonatomic resources such as objects, packets, or simply shared memory. Unfortunately, not everyone can grasp the scope of a whole application at times or can make an accurate prediction of a deadlock occurrence in a large system.

Objective: detect deadlocks at the stage of development, refactoring, or even in production.

Approach: A guarding object lock administration to the code should be partially managed by a set of optimal rules not as bulky as building by a graph, but a simple strategy of acquiring locks in a prioritized order on a single thread.

Solution: Introduction of a new guarding object that behaves alike shared_mutex that can be locked both as unique and as shared, but also supports recursion and manages multiple locking and mixing of locks order in a recursive situation. In order to achieve lock order set of constraints or rules were applied.

Constraints:

  1. Only one thread can acquire a lock for writing in a specific resource at the time, all other threads should be waiting for the lock to be freed.

  1. All threads can acquire a read lock for specific resources given no thread is writing to it.

  1. All locks should be prioritized and taken in a specific order in order to satisfy the situation when accessing multiple guarded resources on the same thread.

  1. Any lock can be taken recursively on the same thread.

  1. A lock can be taken once per thread and any further locking on an object in the same thread will take no effect. It offers partial relief to the 3rd item in this list and further order of lock acquisition can be neglected.

  1. No write lock can be taken on the same thread when it already has acquired a read lock.

Exceptional situations: Throws an exception when the lock on the thread is taken out of order and when a unique write lock is taken after the shared of the same ID mutex.
Detection accuracy: 99%

Advantage of method: Practically caught 10 deadlocks in a real system. Detected 60 potential deadlock situations across 40 job types.
Disadvantages: performance of a lock-taking mechanism may need optimization.

Thanks for your attention,
End of the message.