Python3中交错锁的异常安全处理方案求助

核心问题 #

需要实现交错锁的生命周期（lock1获取→lock2获取→lock1提前释放→lock2释放），同时保证异常（如SIGINT触发的KeyboardInterrupt）发生时，所有持有的锁都能被正确释放，且中间任务可安全获取对应锁不触发死锁。

可靠解决方案：状态跟踪+try-finally锁管理 #

通过显式跟踪每个锁的持有状态，在finally块中统一释放持有的锁，既解决了信号触发时机的风险，又避免了误释放其他线程锁的问题，同时保留原逻辑的一致性。

针对原函数f()的实现

def f():
    hold_lock1 = False
    hold_lock2 = False
    try:
        # 获取lock1并标记持有状态
        lock1.acquire()
        hold_lock1 = True
        task_protected_by_lock1()  # 内部可安全获取lock2（符合全局锁顺序）

        # 获取lock2并标记持有状态
        lock2.acquire()
        hold_lock2 = True
        task_protected_by_lock1_and_lock2()

        # 提前释放lock1，更新持有状态
        lock1.release()
        hold_lock1 = False
        task_protected_by_lock2()  # 内部可安全获取lock1（无循环等待）

        # 释放lock2，更新持有状态
        lock2.release()
        hold_lock2 = False
    finally:
        # 按逆序释放持有的锁，避免资源泄漏
        if hold_lock2:
            lock2.release()
        if hold_lock1:
            lock1.release()

针对更新后的do_task()函数的优化实现

from threading import Lock

lock1 = Lock()  # 保护task的观测与赋值操作
lock2 = Lock()  # 保护task的执行操作
task: callable | Generator

def do_task():
    hold_lock1 = False
    hold_lock2 = False
    try:
        lock1.acquire()
        hold_lock1 = True

        if not validate_task(task):
            task = None
        if task is None:
            return

        # 在释放观测锁前先获取执行锁，保证任务执行的独占性
        lock2.acquire()
        hold_lock2 = True
        task_snapshot = task

        # 释放观测锁，允许其他线程更新task，但执行锁仍持有
        lock1.release()
        hold_lock1 = False

        try:
            if callable(task_snapshot):
                task_snapshot()
            else:
                assert isinstance(task_snapshot, Generator)
                next(task_snapshot)
        except:
            # 异常时更新task状态，需重新获取lock1保护
            with lock1:
                task = None
    finally:
        # 确保所有持有的锁都被释放
        if hold_lock2:
            lock2.release()
        if hold_lock1:
            lock1.release()

方案优势 #

1. 无死锁风险：严格遵循全局锁获取顺序（先lock1后lock2），符合你描述的“无线程持有lock2等待lock1”的前提，中间任务获取锁不会触发循环等待。
2. 异常安全：finally块会在任何异常（包括SIGINT信号）发生时执行，保证持有的锁被释放，彻底避免锁泄漏。
3. 状态准确：通过hold_lockX标记当前线程的锁持有状态，完全避免了误释放其他线程锁的问题。
4. 一致性保障：保持原逻辑中任务的原子性关联，不会出现其他线程篡改资源、破坏任务序列的情况。

关于标准上下文管理器的说明 #

标准with语句设计用于锁的“获取-释放”生命周期完全包裹代码块的场景，无法直接支持你需要的“交错释放”模式。自定义上下文管理器虽能实现，但会增加不必要的复杂度，上述try-finally方案更直观且易于维护。

内容的提问来源于stack exchange，提问作者Yuxuan Zhang