锁和线程同步

illjlack

已于 2024-09-09 20:20:38 修改

阅读量734

点赞数 21

文章标签： c++ linux

于 2024-09-09 20:19:58 首次发布

本文链接：https://blog.csdn.net/m0_62494327/article/details/142067949

版权

悲观锁（Pessimistic Lock）

锁

互斥锁、自旋锁、读写锁（共享锁）、乐观锁、悲观锁

一般加锁的过程，包含两个步骤：

第一步，查看锁的状态，如果锁是空闲的，则执行第二步；
第二步，将锁设置为当前线程持有；

Compare And Swap或者 Test-and-Set 函数就通过硬件，把这两个步骤合并成一条硬件级指令，形成原子指令，这样就保证了这两个步骤是不可分割的，要么一次性执行完两个步骤，要么两个步骤都不执行。

最底层的两种就是「互斥锁和自旋锁」，有很多高级的锁都是基于它们实现的，它们是各种锁的地基，所以我们必须清楚它俩之间的区别和应用。

加锁的目的就是保证共享资源在任意时间里，只有一个线程访问，这样就可以避免多线程导致共享数据错乱的问题。

当已经有一个线程加锁后，其他线程加锁则就会失败，互斥锁和自旋锁对于加锁失败后的处理方式是不一样的：

互斥锁加锁失败后，线程会挂起 (由系统调用实现)，给其他线程；
自旋锁加锁失败后，线程不断尝试(用户自己实现就行)，直到它拿到锁；

自旋锁（Spinlock）

在有些场景中，同步资源的锁定时间很短，为了这一小段时间去切换线程，线程挂起和恢复现场的花费可能会让系统得不偿失。

如果机器有多个CPU核心，能够让两个或以上的线程同时并行执行，我们就可以让后面那个请求锁的线程不放弃CPU的执行时间，看看持有锁的线程是否很快就会释放锁。

为了让当前线程“稍等一下”，我们需让当前线程进行自旋，如果在自旋完成后前面锁定同步资源的线程已经释放了锁，那么当前线程就可以不必阻塞而是直接获取同步资源，从而避免切换线程的开销。这就是自旋锁。

自旋锁是通过 CPU 提供的Compare And Swap或者 Test-and-Set 函数，在「用户态」完成加锁和解锁操作，不会主动产生线程上下文切换，所以相比互斥锁来说，会快一些，开销也小一些。

class Spinlock {
private:
    std::atomic_flag lock_flag = ATOMIC_FLAG_INIT; // 用于表示锁的状态,这个宏其实就是0

public:
    void lock() {
        while (lock_flag.test_and_set(std::memory_order_acquire)) {
            // 自旋等待，CPU空转
            _mm_pause(); // 让出CPU,减少总线争用,（就是执行一个cpu的指令，占一点cpu时间,但是不需要真的计算什么）
        }
    }

    void unlock() {
        lock_flag.clear(std::memory_order_release); // 释放锁
    }
};

问题

当任务线程数多于cpu核数时，忙等不会切换时间片，但又在等待同步，比如8核运行9个线程，效率会下降到1%甚至0.1% (大量需要同步的任务,我没测试出来,大佬测试的数据)

互斥锁（mutex）

互斥锁是一种「独占锁」，比如当线程 A 加锁成功后，此时互斥锁已经被线程 A 独占了，只要线程 A 没有释放手中的锁，线程 B 加锁就会失败，于是就会释放 CPU 让给其他线程，既然线程 B 释放掉了 CPU，自然线程 B 加锁的代码就会被阻塞。

对于互斥锁加锁失败而阻塞的现象，是由操作系统内核实现的。当加锁失败时，内核会将线程置为「睡眠」状态，等到锁被释放后，内核会在合适的时机（通过消息队列或者更优的数据结构）唤醒线程，当这个线程成功获取到锁后，于是就可以继续执行。

所以，互斥锁加锁失败时，会从用户态陷入到内核态，让内核帮我们切换线程，虽然简化了使用锁的难度，但是存在一定的性能开销成本。

那这个开销成本是什么呢？会有两次线程上下文切换的成本：

当线程加锁失败时，内核会把线程的状态从「运行」状态设置为「睡眠」状态，然后把 CPU 切换给其他线程运行；
接着，当锁被释放时，之前「睡眠」状态的线程会变为「就绪」状态，然后内核会在合适的时间，把 CPU 切换给该线程运行。

线程的上下文切换的是什么？当两个线程是属于同一个进程，因为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据、寄存器等不共享的数据。

上下切换的耗时有大佬统计过，大概在几十纳秒到几微秒之间，如果你锁住的代码执行时间比较短，那可能上下文切换的时间都比你锁住的代码执行时间还要长。

#include <iostream>
#include <thread>
#include <mutex>

std::mutex mtx; // 创建一个全局互斥锁
int shared_resource = 0; // 共享资源

// 线程函数，试图修改共享资源
void increment(int thread_id) {
    for (int i = 0; i < 5; ++i) {
        std::lock_guard<std::mutex> lock(mtx); // 自动加锁和解锁
        ++shared_resource; // 修改共享资源
    }
}

int main() {
    std::thread t1(increment, 1); // 创建线程1
    std::thread t2(increment, 2); // 创建线程2

    t1.join(); // 等待线程1结束
    t2.join(); // 等待线程2结束

    std::cout << "Final shared_resource value: " << shared_resource << std::endl;
    return 0;
}

读写锁

共享锁具有独占模式和共享模式。读写锁就是共享锁。

读写锁中，加读锁要等写锁解锁，可以重复加读锁；加写锁要等待读锁和写锁都解锁。

读者是不用修改临界资源的任务，写者是要修改临界资源的任务。

主要作用是在读多修改少的环境中防止频繁阻塞。

这是一个用自旋锁实现的读写锁。

class ReadWriteLock {
public:
    // 获取读锁
    void read_lock() {
        while (write_request_flag_.load()) {
            // 如果有写者等待，读者暂时让出CPU（防止写者饿死）
            std::this_thread::yield();
        }
        if (reader_count_.fetch_add(1) == 0) {
            writer_lock_.lock();  // 如果是第一个读者，则获取写锁
        }
    }

    // 释放读锁
    void read_unlock() {
        if (reader_count_.fetch_sub(1) == 1) {
            writer_lock_.unlock();  // 如果是最后一个读者，则释放写锁
        }
    }

    // 获取写锁
    void write_lock() {
        write_request_flag_.store(true);  // 标记写者请求
        writer_lock_.lock();
    }

    // 释放写锁
    void write_unlock() {
        write_request_flag_.store(false);  // 清除写者请求标记
        writer_lock_.unlock();
    }

private:
    Spinlock writer_lock_; // 用于控制写操作的访问 (可以换成互斥锁)
    std::atomic<int> reader_count_{0}; // 当前活动读者的数量
    std::atomic<bool> write_request_flag_{false}; // 用于标记是否有写者在等待
};