Code RoomLock order deadlock cycle
HardPrep Room Coding #183

Lock order deadlock cycle

CodingConcurrencyAlgorithms & data structuresSenior–Staff~35 min

Given a trace of lock-acquisition attempts, determine whether the program can deadlock under the standard lock-order-cycle heuristic. The trace is a list of ops, each [thread, action, lock] where action is "acquire" or "release". A thread can hold multiple locks at once (nested locking). Build a lock-order graph: whenever a thread acquires lock Y while already holding lock X, add a directed edge X -> Y (X is acquired-before Y by that thread). A potential deadlock exists iff this lock-order graph contains a cycle (two locks acquired in opposite orders by different paths). Return True if a cycle exists, else False. Assume the trace is well-formed (no releasing an unheld lock).

Implement
lock_order_deadlock(ops: list[list]) → bool
Examples
in[[[0,"acquire","A"],[0,"acquire","B"],[0,"release","B"],[0,"release","A"],[1,"acquire","B"],[1,"acquire","A"],[1,"release","A"],[1,"release","B"]]]outtrue
What a strong answer looks like

State your approach and its time/space complexity out loud before you optimize. Handle the edge cases (empty input, duplicates, overflow), and say why you chose this over the brute force. Green tests are the floor, not the grade.

0:00 of about 35 min
InputExpectedGot
[[[0,"acquire","A"],[0,"acquire","B"],[0,"release","B"],[0,"release","A"],[1,"acquire","B"],[1,"acquire","A"],[1,"release","A"],[1,"release","B"]]]truenot run yetsample