Linux中的mutex机制[一] - 加锁和osq lock

发布网友发布时间：2024-09-27 03:06

共1个回答

热心网友时间：2024-10-04 20:25

在Linux系统中，mutex（互斥锁）是实现线程间同步的重要工具，它类似于spinlock（自旋锁）但具有更多特性。相比于spinlock的“自旋”特性，即线程在获取锁时持续占用CPU资源直到释放，mutex采用“阻塞”策略，允许线程在获取锁失败时进行睡眠，从而避免了CPU资源的无效占用。

mutex的基本结构包含了一个spinlock和一个表示等待队列的双向链表（wait_list），以及一个记录锁持有状态的owner指针。当没有线程持有锁时，owner值为0；若线程持有锁，则owner指向该线程的task_struct指针。task_struct指针对齐于L1_CACHE_BYTES，最低三位用于存储额外信息。

早期mutex实现中使用了一个count字段来记录锁的持有状态，值为1表示锁空闲，0表示锁持有，负数表示等待锁的线程。后来，通过重构将count的信息整合到owner中，并新增了一个MUTEX_FLAG_WAITERS位来标识等待队列的存在。

获取mutex的函数主要为mutex_lock_interruptible()，它允许线程在等待锁时睡眠，从而避免了中断上下文的锁争用问题。此函数在没有其他线程持有锁时，可立即获得锁，实现快速路径（fast path），与qspinlock类似。而当存在持有锁的线程时，程序将进入慢路径（slow path），等待锁可用后再唤醒。

在慢路径中，线程会尝试乐观等待，即假定持有锁的线程很快就会释放锁，因此在临界区短暂等待。这种策略被称为mid path（中间路径）或乐观自旋（optimistic spinning），允许线程保持运行状态，从而减少上下文切换的开销。在mid path中的线程被称为spinner，这种机制需要内核配置选项“CONFIG_MUTEX_SPIN_ON_OWNER”。

当另一个线程试图获取同一个锁时，会根据当前CPU的状态决定是否进入mid path。如果当前CPU上没有更高优先级的任务，线程会进入mid path等待；否则，线程会被更高优先级的任务抢占，从而进入慢路径等待。等待线程的身份会从spinner变为waiter，此时线程状态会变为“TASK_INTERRUPTIBLE”，并调用schedule()让出CPU。

当持有锁的线程释放锁时，处于mid path的线程会获取锁，从而进入自己的临界区。如果释放锁时线程正处于睡眠状态，那么它会被重新添加到慢路径等待队列中，身份变为waiter。整个过程涉及公平与效率的权衡，乐观等待机制在提高效率的同时增加了系统复杂性。

至此，mutex的加锁过程已经介绍完毕，下文将详细探讨mutex的解锁过程和死锁问题。

热心网友时间：2024-10-04 20:23