22 / 03 / 08

Linux下几种锁的机制-Mutex/Semaphore/Spinlock

1.Linux并行性特征

Linux作为典型的多用户、多任务、抢占式内核调度的操作系统，为了提高并行处理能力，无论在内核层面还是在用户层面都需要特殊的机制来确保任务的正确性和系统的稳定运行。

在内核层面涉及到各种软硬件中断、进线程睡眠、抢占式内核调度、多处理器SMP架构等，因此内核在完成自己工作的时候一直在处理这些资源抢占的冲突问题。

在用户层面的进程，虽然Linux作为虚地址模式操作系统，为每个进程开辟了独立的虚拟地址空间，伪独占式拥有资源，但是仍然存在很多场景不得不产生多个进程共享资源的问题，来完成进程间的通信。

在线程层面，线程作为进程的一部分，进程内的多个线程只拥有自己的独立堆栈等少量结构，大部分的资源还是过线程共享，因此多线程的资源占用冲突比进程更加明显，所以多线程编程的线程安全问题是个重难点。

综上可知，无论在kernel还是user space都必须有一些机制来确保对于资源共享问题的解决，然后这个机制就是接下来要说的：同步和互斥。

2.Linux下的同步与互斥机制

同步与互斥机制是用于控制多个任务对某些特定资源的访问策略；同步是控制多个任务按照一定的规则或顺序访问某些共享资源；互斥是控制某些共享资源在任意时刻只能允许规定数量的任务访问。

要很好地理解同步和互斥，就必须得搞清楚几个重要术语:

  • 竞争冒险(race hazard)或竞态条件(race condition） 最早听说这个术语是在模电数电的课程上，门电路出现竞态条件造成错误的结果，在计算机里面就是多个使用者同时操作共享的变量造成结果的不确定。

  • 临界区 临界区域critical section是指多使用者可能同时共同操作的那部分代码，比如自加自减操作，多个线程处理时就需要对自加自减进行保护，这段代码就是临界区域。

3.Linux中常用的锁

  • Mutex互斥锁 使用者使用互斥锁时在访问共享资源之前对进行加锁操作，在访问完成之后进行解锁操作，谁加锁谁释放，其他使用者没有释放权限。 加锁后，任何其他试图再次加锁的线程会被阻塞，直到当前进程解锁。 区别于自旋锁，互斥锁无法获取锁时将阻塞睡眠，需要系统来唤醒，可以看出来自旋转自己原地旋转来确定锁被释放了，互斥锁由系统来唤醒，但是现实并不是那么美好的，因为很多业务逻辑系统是不知道的，仍然需要业务线程执行while来轮询是否可以重新加锁。考虑这种情况：解锁时有多个线程阻塞，那么所有该锁上的线程都被编程就绪状态， 第一个变为就绪状态的线程又执行加锁操作，那么其他的线程又会进入等待，对其他线程而言就是虚假唤醒。 在这种方式下，只有一个线程能够访问被互斥锁保护的资源。

  • Spinlock自旋锁 自旋锁的主要特征是使用者在想要获得临界区执行权限时，如果临界区已经被加锁，那么自旋锁并不会阻塞睡眠，等待系统来主动唤醒，而是原地忙轮询资源是否被释放加锁，自旋就是自我旋转，这个名字还是很形象的。自旋锁有它的优点就是避免了系统的唤醒，自己来执行轮询，如果在临界区的资源代码非常短且是原子的，那么使用起来是非常方便的，避免了各种上下文切换，开销非常小，因此在内核的一些数据结构中自旋锁被广泛的使用。

  • Semaphore信号量 不管是mutex还是spinlock，都限定了某一时刻只有一个线程可以获得临界区资源，但在某些场景下，临界区资源允许多个线程同时访问，这时就可以使用semaphore。

Linux中semaphore的定义同mutex很相似，都是包含一个保护该结构体的spinlock和一个等待队列"wait_list"。

struct semaphore {
    raw_spinlock_t    lock;
    unsigned int      count;
    struct list_head  wait_list;
};

semaphore是没有"owner"的，它只需要一个标识共享资源数目的"count"，因而也被称为counting semaphore。

只要semaphore对应的"count"的值大于0，线程获取semaphore就可以成功，但它会使可进入临界区的线程数目减少（对应"count"值减1），所以其函数名为down()，基于存在的和mutex_lock()一样的问题（不能被signal打断），实际多使用的是down_interruptible()。如果count的值小于或等于0，说明当前进入临界区的线程数目已满，那么新的线程只能加入"wait_list"等待队列，进入休眠态。

如果等待队列为空，释放semaphore会使可进入临界区的线程的数目增加（对应count值加1），反之则需要唤醒等待队列中的第一个waiter线程。线程试图获取semaphore时可能因为资源不足，进入睡眠等待，但释放semaphore则不会，因而使用up()即可，不需要"up_interruptible()"之类的函数。

Mutex与Semaphore： 从某种意义上来说，mutex可以被视作是一种"count"值只能为0和1的特殊semaphore，也就是binary semaphore(二值信号量)。但严格地来将，mutex和binary semaphore还是存在一些区别的。

semaphore已经不能算是一种锁了，对于像mutex这样真正的锁，必须遵循“解铃还须系铃人”的原则，也就是“谁占有谁释放”。这在一定程度上限制了mutex的使用，比如一些内核和用户空间之间的交互，但同时也更不容易出错。

  • rwlock读写锁 读写锁也叫共享互斥锁：读模式共享和写模式互斥，本质上这种非常合理，因为在数据没有被写的前提下，多个使用者读取时完全不需要加锁的。读写锁有读加锁状态、写加锁状态和不加锁状态三种状态，当读写锁在写加锁模式下，任何试图对这个锁进行加锁的线程都会被阻塞，直到写进程对其解锁。 读优先的读写锁：读写锁rwlock默认的也是读优先，也就是:当读写锁在读加锁模式先，任何线程都可以对其进行读加锁操作，但是所有试图进行写加锁操作的线程都会被阻塞，直到所有的读线程都解锁，因此读写锁很适合读次数远远大于写的情况。这种情况需要考虑写饥饿问题，也就是大量的读一直轮不到写，因此需要设置公平的读写策略。

  • RCU lock Read Copy Update Lock，读-拷贝-更新锁，是读写锁的扩展版本，简单来说就是支持多读多写同时加锁，多读没什么好说的，但是对于多写同时加锁，还是存在一些技术挑战的。Copy拷贝：写者在访问临界区时，写者将先拷贝一个临界区副本，然后对副本进行修改；Update更新：RCU机制将在在适当时机使用一个回调函数把指向原来临界区的指针重新指向新的被修改的临界区，锁机制中的垃圾收集器负责回调函数的调用。更新时机：没有CPU再去操作这段被RCU保护的临界区后，这段临界区即可回收了，此时回调函数即被调用。从实现逻辑来看，RCU锁在多个写者之间的同步开销还是比较大的，涉及到多份数据拷贝，回调函数等，因此这种锁机制的使用范围比较窄，适用于读多写少的情况，如网络路由表的查询更新、设备状态表更新等，在业务开发中使用不是很多。

  • conditional variable条件变量 条件变量是用来等待线程而不是上锁的，通常和互斥锁一起使用。互斥锁的一个明显的特点就是某些业务场景中无法借助系统来唤醒，仍然需要业务代码使用while来判断，这样效率本质上比较低。而条件变量通过允许线程阻塞和等待另一个线程发送信号来弥补互斥锁的不足，所以互斥锁和条件变量通常一起使用，来让条件变量异步唤醒阻塞的线程。

条件变量和互斥锁的典型使用就是生产者和消费者模型，这个模型非常经典，也在面试中经常被问到，示例代码：

#include <stdio.h>
#include <pthread.h>
#define MAX 5

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t notfull = PTHREAD_COND_INITIALIZER;  //是否队满
pthread_cond_t notempty = PTHREAD_COND_INITIALIZER; //是否队空
int top = 0;
int bottom = 0;

void* produce(void* arg)
{
    int i;
    for ( i = 0; i < MAX*2; i++)
    {
        pthread_mutex_lock(&mutex);
        while ((top+1)%MAX == bottom)
        {
            printf("full! producer is waiting\n");
            //等待队不满
            pthread_cond_wait(notfull, &mutex);
        }
        top = (top+1) % MAX;
        //发出队非空的消息
        pthread_cond_signal(notempty);
        pthread_mutex_unlock(&mutex);
    }
    return (void*)1;
}
void* consume(void* arg)
{
    int i;
    for ( i = 0; i < MAX*2; i++)
    {
        pthread_mutex_lock(&mutex);
        while ( top%MAX == bottom)
        {
            printf("empty! consumer is waiting\n");
            //等待队不空
            pthread_cond_wait(notempty, &mutex);
        }
        bottom = (bottom+1) % MAX;
        //发出队不满的消息
        pthread_cond_signal(notfull);
        pthread_mutex_unlock(&mutex);
    }
    return (void*)2;
}
int main(int argc, char *argv[])
{
    pthread_t thid1;
    pthread_t thid2;
    pthread_t thid3;
    pthread_t thid4;

    int ret1;
    int ret2;
    int ret3;
    int ret4;

    pthread_create(&thid1, NULL, produce, NULL);
    pthread_create(&thid2, NULL, consume, NULL);
    pthread_create(&thid3, NULL, produce, NULL);
    pthread_create(&thid4, NULL, consume, NULL);

    pthread_join(thid1, (void**)&ret1);
    pthread_join(thid2, (void**)&ret2);
    pthread_join(thid3, (void**)&ret3);
    pthread_join(thid4, (void**)&ret4);
    return 0;
}

其中pthread_cond_wait的使用是个需要注意的地方:pthread_cond_wait()是先将互斥锁解开，并陷入阻塞，直到pthread_signal()发出信号后pthread_cond_wait()再加上锁，然后退出。

参考文章

1.https://zhuanlan.zhihu.com/p/104723864 2.https://www.cnblogs.com/TMesh/p/11730847.html

技术记录
Powered by Gridea