linux lock(linux软件仓库)

各位老铁们好，相信很多人对linux lock都不是特别的了解，因此呢，今天就来为大家分享下关于linux lock以及linux软件仓库的问题知识，还望可以帮助大家，解决大家的一些困惑，下面一起来看看吧！

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

在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的解锁过程和死锁问题。

Linux内核中的同步机制:进程的同步同步机制,线程的同步机制

在Linux内核的世界里，同步机制是确保多进程并发执行时资源合理访问的核心手段。同步与互斥，如同一对孪生守护者，守护着数据的完整性与系统的稳定性。当多个进程竞相争夺同一资源时，同步规则便显得尤为重要，它规定了访问的秩序，防止了死锁的滋生。

死锁，这个术语描绘了进程间的恶性循环，每个进程都在等待其他进程释放资源。为避免这种困境，开发者应用了预防、避免、检测和解除策略，其中预防是最优解，通过遵循特定的加锁和解锁规则，比如按顺序加锁解锁，设置超时限制，以及避免不必要的资源请求，来减少死锁的发生。

同步手段多样，原子操作是其中的基础，它们保证操作的完整性，不会因中断或抢占而被打断。例如，atomic_read和atomic_inc这样的函数，确保了数据的准确更新。在实战中，如自旋锁（spin_lock）和读写自旋锁（rwlock），以及信号量（semaphore），各有其适用场景。自旋锁适合处理短暂的临界区，而信号量则适用于长时间等待的场景，它们的使用需结合系统资源和CPU消耗进行权衡。

深入理解内核的同步机制，如自旋锁的spin_lock、spin_lock_irqsave，以及读写锁的read_lock和write_lock，能够帮助开发者编写出高效且安全的并发代码。在编写示例中，我们看到临界区的保护（如DEFINE_SPINLOCK(mr_lock)）以及中断处理时的互斥策略（如spin_lock_irqsave）。

对于信号量和互斥体（mutex），信号量的sem_init、down和up操作提供了更广泛的同步功能，而mutex的简单接口如mutex_lock和mutex_unlock，使得它成为首选。完成变量（completion）则用于任务间的协作，completion.h>提供了相关头文件支持。

值得注意的是，早期的大内核锁（BKL）已被弃用，取而代之的是更为精细的资源保护策略。RCU（Read-Copy Update）扩展了读写锁，为多线程读写操作提供平衡，但需注意其性能开销。而per_cpu变量在内核中扮演着关键角色，尤其是在中断处理和进程同步中，它们是多处理器协作的基石。

最后，学习Linux内核开发并非孤立的知识，它与进程同步、线程同步、通信机制（如管道、信号等）紧密相连。如果你对内核源码、内存调优、文件系统等主题感兴趣，可以通过课程资源，如973961276群组获取更多学习资料和视频教程。踏上探索Linux内核的旅程，让我们一起领略其深度与魅力吧！

「干货」linux文件系统中的“锁”

在多进程共享的应用程序中，通过“锁”来对同一个计算资源进行协同是非常常见的做法，无论在单机或多机的系统、数据库、文件系统中，都需要依赖“锁”机制来避免并发访问导致的不确定结果，今天我们就来讲讲文件系统中的“锁”。

首先，文件锁也是一种互斥机制，可确保多个进程以安全的方式读取/写入同一个文件。之所以要对这些多进程业务进行控制，就是因为这些进程的调度是不可预期的，这种时序上的不可预期会对同一个文件资源产生竞争性访问，从而带来预期外的结果。

我们可以看一个例子，以便更好地理解这个问题。

假设我们有一个 account.dat文件，用于存储帐户余额，其初始值为“200”。并发系统有两个进程来更新这个文件上的余额值：

显然，在顺序执行完这两个进程后，我们期望文件具有以下值：200-20+ 80= 260。

但是，如果进程的执行不是按预期的顺序直径，在以下这种情况下，可能会出现不一样的结果：

结果，account.dat文件中保存的余额就是 280而不是预期值 260。

Linux中的文件锁

像前面提到的，文件锁是一种在多个进程之间限制文件并发访问的机制。它仅允许一个进程在特定时间内访问文件，从而避免更新问题。

我们都知道 rm-rf/在 Linux中是非常危险的命令。如果我们以 root用户身份执行该命令，它甚至可以删除正在运行的系统中的所有文件。这是因为 Linux通常不会自动给打开的文件加锁，所以即使是正在运行的文件，仍然有可能被 rm命令删除。Linux支持两种文件锁：协同锁（Advisory lock）和强制锁（Mandatory lock）。

协同锁（Advisory lock）

协同锁定不是强制性锁方案，仅当参与的进程通过显式获取锁进行协作时，它才有效。否则，如果某个进程根本不知道锁，则这个协同锁会被忽略掉（意味着各个进程间必须协商并遵守这个协同锁的机制，才能发挥锁的作用）。

下面这个例子可以帮助我们更容易地理解协同锁机制。让我们先回顾一下我们之前提到的账户文件的例子。

首先，我们假设文件 account.dat仍包含初始值“200”。

进程 A获取 account.dat文件的排他锁，然后打开并读取该文件以获取当前值：200。

我们必须了解，协同锁不是由操作系统或文件系统设置的。因此，即使进程 A锁定了文件，进程 B仍然可以通过系统调用自由读取、写入或删除文件。

如果进程 B不尝试在获取锁的情况下，就执行文件操作，则可以说进程 B与进程 A没有使用协同锁机制进行合作，仍然会带来不可预期的结果。

现在，让我们看一下锁如何在协作流程中发挥作用：

强制锁（Mandatory Lock）

与协作锁不同，强制锁不需要参与进程之间的任何合作。一旦在文件上激活了强制锁，操作系统便会阻止其他进程读取或写入文件。

要在 Linux中启用强制性文件锁定，必须满足两个要求：

使用强制锁之后，这个锁会在操作系统级别进行管理和控制。