前言：

本篇文章主要讲解了线程互斥的实现方式，还有原理，并附上代码讲解。并且讲解了锁的概念，问题等。

1 线程互斥

还记得我上一篇文章的结尾有提过的问题吗？如果多个线程同时访问同一个全局变量是否会导致什么问题呢？

答案很明确，那就是一定会导致某种错误，那么这种错误是什么呢？请看下面的代码：

#include<iostream>
#include<unistd.h>
#include<pthread.h>
#include<string>
using namespace std;

//1000张票
int Ticket = 1000;
#define NUM 5

//买票
void* buyTicket(void* args)
{
    string name = static_cast<const char*>(args);

    while(1)
    {
        if(Ticket > 0)
        {
            usleep(1000);
            --Ticket;
            cout << name << "购买了一张票，还剩下：" << Ticket<< endl; 
        }
        else
        {
            //没票了就退出
            break;
        }

        usleep(10);
    }

    return nullptr;
}

//创建线程
int main()
{
    pthread_t tids[NUM];
    for(int i = 0; i < NUM; ++i)
    {
        char* name = new char[64];
        snprintf(name,64,"%s-%d","thread",i+1);
        int n = pthread_create(tids+i,nullptr,buyTicket,name);
        if(n != 0)
        {
            cout << "create thread fail" << endl;
        }
    }


    for(int i = 0; i < NUM; ++i)
    {
        int n = pthread_join(tids[i],nullptr);
        if(n != 0)
        {
            cout << "join thread fail" << endl;
        }
    }

    return 0;
}

我先讲解一下这一段代码，首先，我们生成了5个线程，这5个线程都会去执行buyTicket这个函数，其中我们定义的Ticket是一个全局变量，所有的线程都能够访问到这个资源，并且它们都能对这个值进行修改，当这个值从1000变为了0的时候，所有的线程都会退出，那么最终的输出值一定是“某一个线程购买了一张票，还剩下0”，这个样式，但是请看我们的实际输出是什么？

输出很奇怪欸，为什么会出现票的数量被减到了负数呢？这很明显不对吧，这确实不对，那么产生这个问题的原因是什么呢？这就涉及到了我们多线程并发访问的问题咯。

1.1 多线程并发问题

我先问大家一个问题，那就是--Ticket这一句代码，在底层真的是一句指令吗？

我的回答是并不是，现在我就为大家讲解一下，--Ticket的真正运行逻辑。

请大家看到上图，我省略了虚拟地址空间这个步骤。在内存当中才会有真正的Ticket这个变量的位置，这个没问题，当我们进行--Ticket的时候，CPU会去将Ticket的内容加载进来，然后通过运算器运行了之后，再写回我们Ticket内存当中，那么也就是说，就算是我们简化的运算逻辑，都是分了三步才能对一个变量进行--操作，也就证明了我们的--Ticket这个过程并不是原子的。（原子表示一个动作只有完成或则没有开始两种动作，没有正在做这个过程）。

记住了上面的结论，我们再来下一个过程，我们的OS会定期的切换PCB，没有任何一个执行流能够有特权，那么这就会导致一个什么问题呢？那就是当其中一个线程加载Ticket进入CPU，并且运算完成之后，正打算将数据写回到内存当中，这时，时间片到了，没办法只能就此作罢。然后另一个线程又来改Ticket这个变量，能改吗？能改，因为它是有权限的，所以他就疯狂的更改ticket的值，假设Ticket的值变为了100。然后时间片又到了，换回最开始的那个线程，他发现，我上次的Ticket还没有写回内存呢，所以赶紧写入了，Ticket就变为了999。这个时候下一个线程再来访问，Ticket的值正确吗？不对了吧。

可能有小伙伴在这里会有一些疑问，那就是为什么CPU能够认识哪一个线程执行到了那个位置了呢？他又是如何辨别的？其实这一点可以归为一类，那就是我们的线程是由PCB的，还记得我上一篇文章当中讲了线程的私有属性当中有一个什么东西吗？一组寄存器量，没错，这组寄存器会记录下当前CPU里寄存器的值，也就是正在运行的代码的上下文，然后在下一次调用这个线程的时候，通过读取这些寄存器的变量，就能够知道上一次运行到了那个位置了。这就是线程切换不会出现问题的真正原因。

所以因为有了这个问题，所以才出现了线程互斥这个概念。以及锁这个产物。

1.2 线程锁

通过上面的讲解，我们已经明白了为什么会出现多线程访问并发的问题，所以咱们就需要想方法改进咯，那么我们的改进策略就是添加锁。

那么什么是锁呢？其实就是字面意思，谁持有锁，谁就能够打开“某一扇门”，在我们的线程当中，这个门就是临界区的资源。什么又是临界区呢？所谓临界区其实就是含有临界资源的那部分代码，而临界资源又是什么？临界资源就是有可能会被多个线程同时访问的资源，上文的Ticket就是临界资源，所以我们上锁的位置就是线程访问临界区之前。

我们的线程互斥也是基于锁来实现的，也就是说，当一份资源不允许被多个线程同时访问的时候，就需要对这一份资源添加一把锁，这样就可以让所有的执行流在运行到这个地方只能够单执行流运行，而不是多执行流并发访问。

所以更改代码之后如下：

//锁的初始化
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

void* buyTicket(void* args)
{
    string name = static_cast<const char*>(args);

    while(1)
    {
        //上锁
        pthread_mutex_lock(&mutex);
        if(Ticket > 0)
        {
            usleep(1000);
            --Ticket;
            cout << name << "购买了一张票，还剩下：" << Ticket<< endl; 
            //解锁
            pthread_mutex_unlock(&mutex);
        }
        else
        {
            //解锁
            pthread_mutex_unlock(&mutex);
            break;
        }

        //拿到票之后的其它动作
        usleep(10);
    }

    return nullptr;
}

输出如下：

我知道大伙现在脑袋里面懵懵的，首先第一个疑问，我们的临界区是因为不是原子的，从而导致了有多线程并发访问的问题，但是你的锁又是如何保证自己的原子性的呢？

对于锁如何保证自己的原子性的其实很简单，并不是说它是由另一个锁保证的，而是说锁本身就是原子的。

好，说到这里大伙估计更加懵比了，什么玩意哇？锁是原子的，那为什么之前的变量就不是了？这不是搞特殊对待嘛，最关键的是，这是怎么实现的。

请看到锁实现的代码：

lock:(上锁)

movb $0, %al

xchgb %al, mutex

if(al > 0){

return 0;

}else

goto lock;

unlock:

movb $1, mutex

return 0;

上面的代码是锁的实现，al是寄存器，mutex是锁，上锁的逻辑是先将寄存器的值置为0，然后再与mutex交换，如果交换之后，al从零变为了一个非零的值，那么就代表上锁成功，mutex的值也变为了0，程序正确返回，就能够继续向后执行，从而可以使用我们临界区的资源。如果锁之前就已经被拿走了，那么锁与寄存器交换之后，寄存器的值还是0，也就是表明了之前是有人上锁了，所以只能返回回去继续的判断，直到条件申请成功，上锁过程才会结束。

而解锁过程就简单了，直接对锁置一，表示归还锁就行了。

但是这样我并不能感受锁是原子性的，比如交换过程，我就感觉不是原子的，你的疑问确实是有道理的，但是事实上，这个过程就是原子的，因为这属于硬件层面的内容了，它使用了总线锁或者是缓存锁，以次来保证执行这一条指令时是不能够被打断的。

第一个问题我解决了，第二个问题，为什么我在循环当中要添加一个usleep(10)这一句代码来模拟访问临界资源之后的动作呢？不加有什么影响嘛？

删除usleep(10)的影响，输出：

与之前的输出有什么不同？抢票的线程全部变为了1号线程了，这科学吗？这不科学，我明明是多个线程在访问的哇？

其实这个问题理解起来很简单，那就是当前线程持有锁，当它释放锁了之后，后续有没有代码执行，他又返回了循环，又把锁给拿到了，其它线程又只能等待，因为它是正在执行的线程，所以他拿到锁的概率就是最大的。

1.3 锁的接口

这部分博主就不细讲了，本身也没什么难度，只要记得锁的使用场景即可。

锁的初始化，如果用函数接口，那么用了init之后就必须destory，如果用下面的这种方式就不需要这么做了：PTHREAD_MUTEX_INITIALIZER

对于这个函数来说，mutex参数就是我们需要传入的锁，而attr表示锁的一些基本属性，我们不需要管，平时一般都是置为nullptr。

锁的使用：

lock表示上锁，unlock表示解锁，trylock是什么意思呢？其实很简单，trylock表示当我们多次的申请锁不行之后，他就不再申请锁了。

2 线程安全与可重入函数

概念：

线程安全：多个线程并发同一段代码时，不会出现不同的结果。常见对全局变量或者静态变量进行操作，并且没有锁保护的情况下，会出现该问题。

重入：同一个函数被不同的执行流调用，当前一个流程还没有执行完，就有其他的执行流再次进入，我们称之为重入。一个函数在重入的情况下，运行结果不会出现任何不同或者任何问题，则该函数被称为可重入函数，否则，是不可重入函数。

对于一个函数是否可重入其实并不是评判这个函数是否写的优秀与否，甚至可以说毫无关系，因为可重入函数与不可重入函数只是表示这个函数的性质而已。比如我们常见的printf函数他就是不可重入的函数，但是你能说它是写的不好的吗？不可能的。

但是一个函数有线程安全问题，这确实是一个非常严重的事情，因为它会导致我们的程序在某种莫名其妙的情况下崩溃，根本无从下手更改Bug，所以线程安全问题必须规避。

常见的线程不安全的情况：