【Linux多线程】线程互斥 与 常见的锁(无锁化编程)

1. 进程线程间互斥 基本概念

进程互斥的一些基本概念:

  • 临界资源:多线程执行流共享的资源就叫做临界资源。
  • 临界区:每个线程内部,访问临界资源的代码区域,就叫做临界区。
  • 互斥:任何时刻,互斥保证有且只有一个执行流进入临界区,访问临界资源,通常对临界资源起保护作用。
  • 原子性(后面讨论如何实现):不会被任何调度机制打断的操作,该操作只有两态,要么完成,要么未完成。

2. 互斥量mutex

  • 大部分情况,线程使用的数据都是局部变量,变量的地址空间在线程栈空间内,这种情况,变量归属单个线程,其他线程无法获得这种变量。

  • 但有时候,很多变量都需要在线程间共享,这样的变量称为共享变量,可以通过数据的共享,完成线程之间的交互。

  • 多个线程并发的操作共享变量,会带来一些问题。

需要解决的3个问题:

  • 互斥行为:代码必须确保在进入临界区执行时,不允许其他线程进入该临界区。
  • 独占进入:如果多个线程同时要求执行临界区的代码,并且临界区没有线程在执行,那么只能允许一个线程进入该临界区。
  • 不干扰其他线程:如果线程不在临界区中执行,该线程不能阻止其他线程进入临界区。

要解决这些问题,本质就是需要一把锁,而linux提出了互斥量的概念:

在这里插入图片描述


2.1 互斥量的接口

① 初始化

初始化互斥量有两种方法:(即静态分配与动态分配)

  1. 静态分配:
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER
  1. 动态分配:
int pthread_mutex_init(pthread_mutex_t *restrict mutex, const pthread_mutexattr_t*restrict attr);
  • 参数
    • mutex:要初始化的互斥量
    • attr:NULL

② 销毁

销毁互斥量时的注意事项:

  • 自动初始化的互斥量:使用 PTHREAD_MUTEX_INITIALIZER 初始化的互斥量不需要销毁。
  • 加锁状态:不能销毁一个已经加锁的互斥量。
  • 销毁后的使用:已销毁的互斥量,需确保后续不会有线程再尝试加锁。
int pthread_mutex_destroy(pthread_mutex_t *mutex);

③ 加锁 与 解锁

int pthread_mutex_lock(pthread_mutex_t *mutex);
int pthread_mutex_unlock(pthread_mutex_t *mutex);
  • 返回值 : 成功返回0,失败返回错误号

调用 pthread_mutex_lock 时的可能情况:

  • 未锁状态:如果互斥量处于未锁状态,函数将锁定互斥量并返回成功。
  • 已锁状态:如果其他线程已经锁定互斥量,或存在其他线程同时申请互斥量但未竞争到,则 pthread_mutex_lock 调用会陷入阻塞,等待互斥量解锁。

2.2 线程互斥代码实例

下面模拟一个购票抢票的例子:

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

std::mutex mtx; // 互斥锁
int tickets = 10; // 票数

void sell_tickets(int tid) {
    int n = 2; // 每个线程卖票次数
    while(n--) {
        mtx.lock(); // 加锁
        if (tickets > 0) {
            // 模拟买票操作
            std::cout << "Thread " << tid << " sells ticket " << tickets << std::endl;
            tickets--;
        } else {
            mtx.unlock(); // 解锁
            break;
        }

        mtx.unlock();
        // std::this_thread::sleep_for(std::chrono::milliseconds(10)); // 模拟处理时间
    }
}

int main()
{
    std::vector<std::thread> threads;

    // 创建多个线程买票
    for(int i = 0; i < 5; ++i) {
        threads.emplace_back(sell_tickets, i);
    }

    // 等待所有线程结束
    for(auto& t : threads) {
        t.join();
    }

    std::cout << "All tickets sold." << std::endl;
    return 0;
}

执行代码后,会输出整个过程:

在这里插入图片描述


2.3 可重入VS线程安全

① 概念

重入与线程安全:

  • 重入:当同一个函数在不同的执行流中被调用,而前一个流尚未完成时,称为重入。若函数在重入情况下仍能保证运行结果一致且无问题,则称为可重入函数;否则为不可重入函数。

  • 线程安全:多个线程并发执行相同代码段时,结果保持一致,则称为线程安全。常见的问题发生在对全局或静态变量操作且未加锁保护的情况下。


② 常见的线程不安全情况

  • 不保护共享变量的函数
  • 状态随着被调用而发生变化的函数
  • 返回指向静态变量指针的函数
  • 调用线程不安全函数的函数

③ 常见的线程安全情况

  • 每个线程对全局变量或者静态变量只有读取的权限,而没有写入的权限,一般来说这些线程是安全的
  • 类或者接口对于线程来说都是原子操作
  • 多个线程之间的切换不会导致该接口的执行结果存在二义性

④ 常见不可重入情况

  • 调用了malloc/free函数,因为malloc函数是用全局链表来管理堆的
  • 调用了标准I/O库函数,标准I/O库的很多实现都以不可重入的方式使用全局数据结构
  • 可重入函数体内使用了静态的数据结构

⑤ 常见可重入情况

  • 不使用全局变量或静态变量
  • 不使用用malloc或者new开辟出的空间
  • 不调用不可重入函数
  • 不返回静态或全局数据,所有数据都有函数的调用者提供
  • 使用本地数据,或者通过制作全局数据的本地拷贝来保护全局数据

⑥ 可重入与线程安全的联系

  • 函数是可重入的,那就是线程安全的
  • 函数是不可重入的,那就不能由多个线程使用,有可能引发线程安全问题
  • 如果一个函数中有全局变量,那么这个函数既不是线程安全也不是可重入的

⑦ 可重入与线程安全的区别

  • 可重入函数是线程安全函数的一种
  • 线程安全不一定是可重入的,而可重入函数则一定是线程安全的。
  • 如果将对临界资源的访问加上锁,则这个函数是线程安全的,但如果这个重入函数若锁还未释放则会产生死锁,因此是不可重入的

3. 死锁

死锁是指在一组进程中的各个进程均占有不会释放的资源但因互相申请被其他进程所站用不会释放的资源而处于的一种永久等待状态


3.1 死锁的四个必要条件

  • 互斥条件:一个资源每次只能被一个执行流使用。

  • 请求与保持条件:一个执行流因请求资源而阻塞时,对已获得的资源保持不放。

  • 不剥夺条件:一个执行流已获得的资源,在未使用完之前,不能被强行剥夺。

  • 循环等待条件:若干执行流之间形成一种头尾相接的循环等待资源的关系。


3.2 避免死锁

  • 加锁顺序一致
  • 避免锁未释放的场景
  • 资源一次性分配

3.3 避免死锁的相关算法


资源分配图算法

原理:

资源分配图是一种图形模型,用于表示进程和资源之间的关系。图中的节点有两种:进程节点和资源节点。图的边有三种类型:

  • 请求边:从进程到资源,表示进程请求某个资源。

  • 分配边:从资源到进程,表示资源被进程占用。

  • 循环边:形成一个循环,表示系统中存在潜在的死锁。

检测步骤:

  1. 创建资源分配图。
  2. 检测图中是否存在循环。如果存在循环,则表示系统可能存在死锁。

银行家算法

原理:
虽然银行家算法主要用于避免死锁,但它也可用于检测死锁。当系统处于不安全状态时,可以通过分析当前资源分配和进程需求来确定是否存在死锁。

检测步骤:

  1. 分析当前资源分配和进程的最大需求。
  2. 判断系统是否能满足所有进程的需求,以便使每个进程完成。如果无法完成所有进程,则系统可能存在死锁。

等待图算法

原理:
等待图是一个有向图,其中节点表示进程和资源,边表示进程对资源的请求和资源的分配。

检测步骤:

  1. 创建等待图。
  2. 检查图中是否存在环。如果存在环,说明系统可能存在死锁。

4. 检测算法的具体步骤

  1. 构建系统状态的资源分配矩阵和需求矩阵

    • 资源分配矩阵:表示当前资源分配状态。
    • 需求矩阵:表示每个进程所需的资源。
  2. 模拟资源分配和进程执行

    • 尝试找到一种资源分配方式,使系统能够逐步满足所有进程的需求,确保所有进程可以完成。
  3. 判断是否有进程无法完成

    • 如果所有进程都能够完成,则系统没有死锁。
    • 如果有进程无法完成,则系统存在死锁。

5. 实际应用

在实际系统中,死锁检测通常与死锁预防和避免策略结合使用,以降低死锁的发生率。在大规模的操作系统和数据库系统中,死锁检测算法帮助系统管理员和调度程序识别和解决死锁问题,确保系统的正常运行。


4. 其他常见锁

悲观锁

  • 定义:悲观锁是一种锁机制,假设在访问数据时,数据可能会被其他线程修改。因此,在每次访问数据前都会加锁(例如:读锁、写锁、行锁等),以确保数据的一致性和完整性。
  • 特点
    • 线程在访问数据前必须获得锁,其他线程在锁释放之前无法访问这些数据。
    • 在高并发情况下,可能会导致线程阻塞和性能下降。

乐观锁

  • 定义:乐观锁是一种锁机制,假设在访问数据时,数据不会被其他线程修改。在更新数据之前,通过检查数据是否被修改来确保数据一致性。
  • 实现方式
    • 版本号机制:每个数据项都有一个版本号。线程在读取数据时会保存这个版本号。在更新数据时,会检查数据的版本号是否和读取时的一致,若一致则更新,否则更新失败。
    • CAS操作(Compare-And-Swap):线程在更新数据前会检查当前值是否和之前读取的一致。如果一致则进行更新,否则更新失败,通常会重试这个过程。

CAS操作

  • 定义:CAS(比较和交换)操作是乐观锁的一种实现方式。当需要更新数据时,首先检查当前内存中的值是否与之前读取的值相等。如果相等,则更新为新值;如果不等,则操作失败并通常会重试。
  • 特点
    • 原子性:CAS操作是原子性的,即在执行过程中不会被中断。
    • 自旋:通常是一个自旋的过程,即不断重试直到成功。
    • 适用场景:适用于数据冲突不频繁的场景,因为频繁的重试可能会导致性能问题。

锁类型

  • 自旋锁

    • 定义:自旋锁是一种锁机制,线程在尝试获取锁时,会持续循环检查锁的状态,而不是直接阻塞。如果锁被其他线程持有,线程会一直自旋等待,直到锁可用。
    • 特点:适用于锁持有时间较短的场景,因为频繁自旋会消耗CPU资源。
  • 公平锁

    • 定义:公平锁是一种锁机制,确保锁的获取遵循一定的公平性原则。即按请求锁的顺序,线程会被逐一唤醒,避免了“饥饿”现象。
    • 特点:确保每个线程都能公平地获得锁,但可能会导致性能下降,因为需要维护锁请求的队列。
  • 非公平锁

    • 定义:非公平锁是一种锁机制,不保证线程获取锁的顺序。线程可能会在某些情况下跳过排队的线程,直接获得锁。
    • 特点:性能通常比公平锁更高,因为没有额外的队列管理开销,但可能导致某些线程长时间无法获取锁。
  • 5
    点赞
  • 17
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值