| 操作系统 | 核心数 |
|---|---|
| centos 3.10.0 | 32位单核 |
线程之线程安全
- 线程不安全的现象
- 互斥
- 死锁
- 线程饥饿
线程不安全的现象
进程线程的背景概念：
临界资源：多线程执行流之间共享的资源
临界区：每个线程内部，访问临界资源的代码
互斥：任何时刻，互斥保证有且只有一个执行流线程进入临界区，访问临界资源
原子性：不会被任何机制打断，本质上，当某个线程在进入临界区访问临界资源时，其从外部看来是原子性的（也就是说，要么当前这段代码已经执行完了，要么当前代码还没有被执行）。
模拟一个抢票售票代码
#include<stdio.h>
#include<unistd.h>
#include<pthread.h>
#define THREADCOUNT 2
int ticket = 100;
void* Getticket(void *arg)
{
while(1)
{
if(ticket > 0)
{
printf("thread:%p, get ticket%d\n", pthread_self(), --ticket);
usleep(1000);
}
else{
break;
}
}
return NULL;
}
int main()
{
pthread_t tid[THREADCOUNT];
int i, j;
for(i = 0; i < THREADCOUNT; ++i)
{
int ret = pthread_create(&tid[i], NULL, Getticket, NULL);
if(ret < 0)
{
perror("pthread_create");
return 0;
}
}
for(j = 0; j < THREADCOUNT; ++j)
{
pthread_join(tid[j], NULL);
}
return 0;
}
可以看到结果是两个抢票线程抢到了票，而且出现了抢到同一张票，还出现了抢到负数票的情况。当然，前提是需要运行在多核机器下的
出现这种情况的原因：
1.当代码进入到if语句后，usleep(1000)模拟复杂的业务逻辑，这时候可能会有另外一个线程进入临界区访问临界资源，这意味着同时会有多个线程操作临界资源
2.而对于自减操作来说，它本身不是原子性的（对应三条汇编指令，在这三条汇编指令执行的过程中，很有可能其他线程对这块临界资源进行了访问），意味着当它进行自减操作过程中，有其他线程对其操作的临界资源也进行了操作。
3.那么就会导致出现抢到同一张票，还会出现抢到负数票。
互斥
我们要解决上述的问题，就要解决下面三点问题：
1.当代码进入临界区执行时，不能让其他线程进入该临界区
2.当有多个线程都要执行临界区代码时，临界区没有线程在执行代码，那么只能允许一个线程进入临界区
3.如果线程不在临界区执行代码，那么也不能阻止其他线程执行临界区代码
要做到这三点，实际上就是需要一把锁，Linux中提供的这把锁称为互斥锁。
互斥锁的接口：
初始化互斥锁：
//1.静态分配
pthread_mutex_t mutex = PTHREAD_MUTEX_INITALIZER;
//2.动态分配
int pthread_mutex_init(pthread_mutex_t *restrict mutex, const pthread_mutexattr_t *restrict attr);
参数：
mutex：要初始化的互斥锁
attr:NULL
销毁互斥锁：注意，使用静态初始化的互斥锁不需要销毁，不要销毁一个已经加锁的互斥锁，已经销毁的互斥锁，要确保不会再被加锁
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，则当前线程拿到当前的互斥锁，并且将互斥锁置为1.
当前互斥锁处于已经加锁状态1，或者存在其他线程同时申请互斥锁，但是当前线程没有竞争到互斥锁，则当前线程会在pthread_lock函数的地方阻塞等待，等待互斥锁解锁，并再次进行竞争。
那么有了互斥锁后，遇到临界区，我们可以将临界区代码使用互斥锁进行保护，保证临界资源访问的原子性。
那么上述的抢票代码就可以修改为：
#include<stdio.h>
#include<unistd.h>
#include<pthread.h>
#define THREADCOUNT 2
int ticket = 100;
pthread_mutex_t mutex;
void* Getticket(void *arg)
{
while(1)
{
pthread_mutex_lock(&mutex);
if(ticket > 0)
{
printf("thread:%p, get ticket%d\n", pthread_self(), --ticket);
usleep(1000);
pthread_mutex_unlock(&mutex);
}
else{
pthread_mutex_unlock(&mutex);
break;
}
}
return NULL;
}
int main()
{
pthread_mutex_init(&mutex);
pthread_t tid[THREADCOUNT];
int i, j;
for(i = 0; i < THREADCOUNT; ++i)
{
int ret = pthread_create(&tid[i], NULL, Getticket, NULL);
if(ret < 0)
{
perror("pthread_create");
return 0;
}
}
for(j = 0; j < THREADCOUNT; ++j)
{
pthread_join(tid[j], NULL);
}
pthread_mutex_destroy(&mutex);
return 0;
}
我们需要在线程访问临界区之前加上互斥锁，在线程任何可能会退出的地方释放锁。
请注意：在使用锁之前要对互斥锁初始化，并且在全局变量中进行锁的定义，在主线程也就是用到互斥锁的线程创建之前就要初始化好互斥锁，在互斥锁用完之后的主线程中销毁锁。
我们要理解的是：在进入临界区之前加互斥锁，并不代表当前这个线程在执行临界区代码时不会被切换，而是说，即时被切换掉了，这部分临界资源也不允许其他线程对其进行访问，直到当前这个线程下一次被切换回来。
对于互斥，还会出现两种问题：
1.加锁的多线程代码是有可能会出现死锁的情况的
2.只有互斥的代码，线程也可能会有饥饿的情况
死锁
对于死锁，死锁可能出现的原因有两类：
1.加锁后不解锁或者带锁退出
2.多个线程拿着自己的锁，同时在请求其他线程的锁
对于第一个出现死锁的原因，我们可以直接从代码中看出来，但是对于第二种原因，如果当前线程在运行中死锁了，我们很难从代码中看出问题，而且如果还要求我们需要在程序运行中进行调试，这个调试难度就非常大了。
对于第一种原因，我们可以通过代码分析：
void* Get(void* arg)
{
while(1)
{
//进入临界区之前，加锁
pthread_mutex_lock(&lock);
//判断满足条件，执行业务代码
if(ticket > 0)
{
ticket--;
//不满足条件时，退出，这时候发现上次加了锁，没有解锁就退出了，
}else{
//带着锁退出后，线程退出，锁永远不会被解开了
break;
}
//临界区代码结束后，需要解锁，否则下次循环的时候，锁没有被解，下次其他线程永远拿不到锁
}
return NULL;
}
因为当出现多个线程同时在运行，并且拿着自己的锁，还在请求其他线程的锁，出现了死锁，是非常难以排查的。
用代码演示，当AB两个线程都拥有自己的锁AB，同时又在请求对方的锁BA。
运行结果来看：程序好像卡在了某个地方不动了，通过pstack 进程ID发现AB线程都在lock_wait的地方被阻塞了。
原来是我们的线程AB都在lock_wait，都处于等待加锁的状态。
但是我们并不能知道，到底是在等待哪一把锁（因为A线程已经拿到自己的A锁，B线程也拿到自己的B锁了），
这就需要我们使用gbd调试，gdb调试请移步这篇博客Linux下的gbd调试，你学废了吗
线程饥饿
而如果只保证了互斥，还有可能会出现“线程饥饿的问题”
例如如下代码：
void* Get(void* arg)
{
pthread_detach(pthread_self());
while(1)
{
pthread_mutex_lock(&lock);
printf("Get thread, Get ticket\n", ticket);
ticket--;
pthread_mutex_unlock(&lock);
}
return NULL;
}
void* Set(void* arg)
{
pthread_detach(pthread_self());
while(1)
{
pthread_mutex_lock(&lock);
printf("Set thread, Set ticket\n", ticket);
++ticket;
pthread_mutex_unlock(&lock);
}
return NULL;
}
int main()
{
pthread_mutex_init(&lock);
pthread_t Thread_A, Thread_B;
pthread_create(&Thread_A, NULL, Get, NULL);
pthread_create(&Thread_B, NULL, Set, NULL);
pthread_mutex_destroy(&lock);
}
这时候发现，Get线程一直拿着锁，对ticket进行减操作，而Set线程没有机会拿到锁，这就被称为线程饥饿问题，当前的Set线程就是饥饿的。
当前出现线程饥饿问题的原因是：虽然线程被创建出来后是抢占式执行的，但是由于set和get线程的创建顺序是不同的，get线程先被创建，那么当set线程被创建出来的时候，get线程已经拿到了锁，执行了自己的代码，而set线程在等待拿锁，当get执行完代码，释放锁后，下次循环又比set先一步拿到锁。这样就造成了set线程的饥饿。
