用 try-lock 修好它
场景：另一份 trylock.py 也会死锁，说明要求用 try-lock 改。 任务：把死等的 acquire() 改成拿不到就松手重试（acquire(timeout=…) 失败则释放已持有的再重来），让它不再卡死。改好运行 ~/che
改完还会不会偶发死锁
场景：改完后要判断它是否彻底不死锁（不是碰运气）。 任务：判断修好的版本是否任何调度下都不死锁（True/False），到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里对卡死程序做出的证据/修复，不碰公网。） （本机受控
这个线程此刻持有哪把锁
场景：~/dl/看状态.sh 能看到卡死时每个线程已经拿到了哪把锁。 任务：看某个线程此刻持有（已拿到）的是哪把锁，到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里对卡死程序做出的证据/修复，不碰公网。） （本机受控环境
交付:一个不会死锁的版本
场景：要交付一个既能完成工作、又保证不死锁的多线程程序（要求见说明）。 任务：改 ~/dl/deadlock.py（统一锁顺序或 try-lock 皆可），让它稳定跑到结束、打印说明要的结果。改好运行 ~/check。 （判分只看你在受控容
从卡死进程取证据先看什么
面对一个卡死的多线程进程，取证的第一步是【0】。 （本机受控：python3 卡死程序 + 导出的线程栈/状态文件，靠它们判，不掐时间。）
从证据认死锁
下面哪些证据能坐实「这是死锁」而非单纯的慢？ A. 多个线程都停在 acquire（等锁） B. CPU 占用几乎为 0 C. 各线程持有/等待的锁连成了环 D. 长时间状态完全不变
几个线程卡在等锁
场景：~/dl/stacks.txt 是卡死时导出的各线程栈。 任务：数有几个线程此刻停在等锁（acquire）上，到 ~/对照表.txt 里查那个数对应的标记。 （判分只看你在受控容器里对卡死程序做出的证据/修复，不碰公网。） （本机受控
谁持有那把抢手的锁
场景：一把锁被很多线程等着。 任务：从证据看这把锁此刻被哪个线程持有，到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里对卡死程序做出的证据/修复，不碰公网。） （本机受控环境：python3 跑会互等卡死的多线程程序，靠
等待关系成环了吗
场景：~/dl/waitfor.txt 列了「谁等谁」。 任务：判断这些等待关系是否连成了环（True/False），到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里对卡死程序做出的证据/修复，不碰公网。） （本机受控环
环上有几个线程
场景：等待关系已确认成环。 任务：数环上有几个线程，到 ~/对照表.txt 里查那个数对应的标记。 （判分只看你在受控容器里对卡死程序做出的证据/修复，不碰公网。） （本机受控环境：python3 跑会互等卡死的多线程程序，靠栈/状态取证，