This adds the following routes to the scheduler
multi_lock_acquire
multi_lock_release
The approach is to maintain :None:None:`self.locks` that maps a lock (unique name given to :None:None:`MultiLock(names=, ...)` at creation) to a list of users (instances of MultiLock
) that "requests" the lock. Additionally, :None:None:`self.requests` maps a user to its requested locks and :None:None:`self.requests_left` maps a user to the number of locks still need.
Every time a user :None:None:`x` gets to the front in :None:None:`self.locks[name] = [x, ...]` it means that :None:None:`x` now holds the lock :None:None:`name` and when it holds all the requested locks :None:None:`acquire()` can return.
Finally, :None:None:`self.events` contains all the events users are waiting on to finish.
An extension for the scheduler to manage MultiLocks
Hover to see nodes names; edges to Self not shown, Caped at 50 nodes.
Using a canvas is more power efficient and can get hundred of nodes ; but does not allow hyperlinks; , arrows or text (beyond on hover)
SVG is more flexible but power hungry; and does not scale well to 50 + nodes.
All aboves nodes referred to, (or are referred from) current nodes; Edges from Self to other have been omitted (or all nodes would be connected to the central node "self" which is not useful). Nodes are colored by the library they belong to, and scaled with the number of references pointing them
