基于锁的共享资源同步中所有权含义及跨线程改锁变量的疑问

1. 基于锁的共享资源同步中，ownership（所有权）的含义是什么？ #

在基于锁的同步模型里，锁的所有权指的是某个线程通过合法的lock操作成功获取锁之后，获得的对这把锁的独占控制权限。简单来说：

• 持有所有权的线程是当前唯一被允许访问该锁保护的共享资源的线程（针对排他锁场景）；
• 只有持有所有权的线程才有资格调用unlock操作释放锁；
• 所有权是线程与锁之间的临时绑定关系，直到线程主动释放锁，或者在异常场景下（比如线程崩溃）锁被强制回收，这个绑定才会解除。

举个现实例子：就像你拿到了公司会议室的门禁卡（锁），刷卡进入（获取锁）之后，你就拥有了这个会议室的使用权（所有权），其他人无法进入，只有你离开时刷卡开门（释放锁），别人才能使用。

2. 若某线程持有锁，能否在另一线程的代码中执行lock->available = 1（将锁变量设为可用状态）？若可行，为何要求‘lock和unlock调用的所有者必须为同一线程’？ #

从技术底层的内存操作角度，如果lock是一个普通的内存变量，另一个线程确实可以直接修改lock->available = 1——毕竟内存是线程共享的，只要有访问权限就能写。但这么做是极度危险的，而要求lock和unlock必须由同一线程调用，恰恰是为了避免这类危险操作带来的同步灾难：

• 破坏共享资源的互斥性：假设线程A持有锁正在修改共享数据，线程B直接把锁设为可用，那么线程C就会成功获取锁，也开始修改同一共享数据，瞬间就会出现竞态条件，导致数据错乱、程序行为异常；
• 破坏锁的内部状态：现代的锁实现（比如POSIX的pthread_mutex_t）远不止一个available变量，通常还会记录锁的持有者ID、递归计数（针对递归锁）等元数据。直接修改available会让锁的内部状态不一致，后续的锁操作会出现不可预期的错误；
• 避免误操作的防护机制：要求同一线程调用lock和unlock，是锁实现的一种自我保护。比如很多锁库会在unlock时检查调用线程是否是锁的持有者，如果不是就直接返回错误，防止开发者不小心写出跨线程释放锁的bug；
• 保证同步逻辑的可追溯性：如果允许任意线程释放锁，代码的同步逻辑会变得混乱，很难排查死锁、数据竞争这类问题——你根本不知道是谁释放了锁，也无法跟踪锁的流转路径。

所以哪怕技术上能做到跨线程修改锁的可用状态，也绝对不能这么做，而锁实现强制要求lock和unlock同属一个线程，是为了保证同步机制的正确性和代码的可维护性。

内容的提问来源于stack exchange，提问作者Henok Tesfaye