【Linux】线程池 | 自旋锁

文章目录

一.Linux线程池
- 1.线程池的概念
- 2.线程池的优点
- 3.线程池的应用场景
- 4.线程池的实现
二.其他常见的锁
- 1.STL、智能指针和线程安全
- 2.其他常见的锁
三.读者写者问题
- 1.读者写者模型
- 2.读写锁

一.Linux线程池

1.线程池的概念

线程池是一种线程使用模式。

线程过多会带来调度开销，进而影响缓存局部和整体性能，而线程池维护着多个线程，等待着监督管理者分配可并发执行的任务。

2.线程池的优点

线程池避免了在处理短时间任务时创建与销毁线程的代价。
线程池不仅能够保证内核充分利用，还能防止过分调度。

注意： 线程池中可用线程的数量应该取决于可用的并发处理器、处理器内核、内存、网络sockets等的数量。

3.线程池的应用场景

线程池常见的应用场景如下：

需要大量的线程来完成任务，且完成任务的时间比较短。
对性能要求苛刻的应用，比如要求服务器迅速响应客户请求。
接受突发性的大量请求，但不至于使服务器因此产生大量线程的应用。

4.线程池的实现

下面我们实现一个简单的线程池，线程池中提供了一个任务队列，以及若干个线程（多线程）。

在这里插入图片描述

线程池中的多个线程负责从任务队列当中拿任务，并将拿到的任务进行处理。
线程池对外提供一个Push接口，用于让外部线程能够将任务Push到任务队列当中。

线程池的代码如下：

#pragma once#include <iostream>
#include <unistd.h>
#include <queue>
#include <pthread.h>#define NUM 5//线程池
template<class T>
class ThreadPool
{
private:bool IsEmpty(){return _task_queue.size() == 0;}void LockQueue(){pthread_mutex_lock(&_mutex);}void UnLockQueue(){pthread_mutex_unlock(&_mutex);}void Wait(){pthread_cond_wait(&_cond, &_mutex);}void WakeUp(){pthread_cond_signal(&_cond);}
public:ThreadPool(int num = NUM): _thread_num(num){pthread_mutex_init(&_mutex, nullptr);pthread_cond_init(&_cond, nullptr);}~ThreadPool(){pthread_mutex_destroy(&_mutex);pthread_cond_destroy(&_cond);}//线程池中线程的执行例程static void* Routine(void* arg){pthread_detach(pthread_self());ThreadPool* self = (ThreadPool*)arg;//不断从任务队列获取任务进行处理while (true){self->LockQueue();while (self->IsEmpty()){self->Wait();}T task;self->Pop(task);self->UnLockQueue();task.Run(); //处理任务}}void ThreadPoolInit(){pthread_t tid;for (int i = 0; i < _thread_num; i++){pthread_create(&tid, nullptr, Routine, this); //注意参数传入this指针}}//往任务队列塞任务（主线程调用）void Push(const T& task){LockQueue();_task_queue.push(task);UnLockQueue();WakeUp();}//从任务队列获取任务（线程池中的线程调用）void Pop(T& task){task = _task_queue.front();_task_queue.pop();}
private:std::queue<T> _task_queue; //任务队列int _thread_num; //线程池中线程的数量pthread_mutex_t _mutex;pthread_cond_t _cond;
};

为什么线程池中需要有互斥锁和条件变量？

线程池中的任务队列是会被多个执行流同时访问的临界资源，因此我们需要引入互斥锁对任务队列进行保护。

线程池当中的线程要从任务队列里拿任务，前提条件是任务队列中必须要有任务，因此线程池当中的线程在拿任务之前，需要先判断任务队列当中是否有任务，若此时任务队列为空，那么该线程应该进行等待，直到任务队列中有任务时再将其唤醒，因此我们需要引入条件变量。

当外部线程向任务队列中Push一个任务后，此时可能有线程正处于等待状态，因此在新增任务后需要唤醒在条件变量下等待的线程。

注意：

当某线程被唤醒时，其可能是被异常或是伪唤醒，或者是一些广播类的唤醒线程操作而导致所有线程被唤醒，使得在被唤醒的若干线程中，只有个别线程能拿到任务。此时应该让被唤醒的线程再次判断是否满足被唤醒条件，所以在判断任务队列是否为空时，应该使用while进行判断，而不是if。
pthread_cond_broadcast函数的作用是唤醒条件变量下的所有线程，而外部可能只Push了一个任务，我们却把全部在等待的线程都唤醒了，此时这些线程就都会去任务队列获取任务，但最终只有一个线程能得到任务。一瞬间唤醒大量的线程可能会导致系统震荡，这叫做惊群效应。因此在唤醒线程时最好使用pthread_cond_signal函数唤醒正在等待的一个线程即可。
当线程从任务队列中拿到任务后，该任务就已经属于当前线程了，与其他线程已经没有关系了，因此应该在解锁之后再进行处理任务，而不是在解锁之前进行。因为处理任务的过程可能会耗费一定的时间，所以我们不要将其放到临界区当中。
如果将处理任务的过程放到临界区当中，那么当某一线程从任务队列拿到任务后，其他线程还需要等待该线程将任务处理完后，才有机会进入临界区。此时虽然是线程池，但最终我们可能并没有让多线程并行的执行起来。

为什么线程池中的线程执行例程需要设置为静态方法？

使用pthread_create函数创建线程时，需要为创建的线程传入一个Routine（执行例程），该Routine只有一个参数类型为void的参数，以及返回类型为void的返回值。

而此时Routine作为类的成员函数，该函数的第一个参数是隐藏的this指针，因此这里的Routine函数，虽然看起来只有一个参数，而实际上它有两个参数，此时直接将该Routine函数作为创建线程时的执行例程是不行的，无法通过编译。

静态成员函数属于类，而不属于某个对象，也就是说静态成员函数是没有隐藏的this指针的，因此我们需要将Routine设置为静态方法，此时Routine函数才真正只有一个参数类型为void*的参数。

但是在静态成员函数内部无法调用非静态成员函数，而我们需要在Routine函数当中调用该类的某些非静态成员函数，比如Pop。因此我们需要在创建线程时，向Routine函数传入的当前对象的this指针，此时我们就能够通过该this指针在Routine函数内部调用非静态成员函数了。

任务类型的设计

我们将线程池进行了模板化，因此线程池当中存储的任务类型可以是任意的，但无论该任务是什么类型的，在该任务类当中都必须包含一个Run方法，当我们处理该类型的任务时只需调用该Run方法即可。

例如，下面我们实现一个计算任务类：

#pragma once#include <iostream>//任务类
class Task
{
public:Task(int x = 0, int y = 0, char op = 0): _x(x), _y(y), _op(op){}~Task(){}//处理任务的方法void Run(){int result = 0;switch (_op){case '+':result = _x + _y;break;case '-':result = _x - _y;break;case '*':result = _x * _y;break;case '/':if (_y == 0){std::cerr << "Error: div zero!" << std::endl;return;}else{result = _x / _y;}break;case '%':if (_y == 0){std::cerr << "Error: mod zero!" << std::endl;return;}else{result = _x % _y;}break;default:std::cerr << "operation error!" << std::endl;return;}std::cout << "thread[" << pthread_self() << "]:" << _x << _op << _y << "=" << result << std::endl;}
private:int _x;int _y;char _op;
};

此时线程池内的线程不断从任务队列拿出任务进行处理，而它们并不需要关心这些任务是哪来的，它们只需要拿到任务后执行对应的Run方法即可。

主线程逻辑

主线程就负责不断向任务队列当中Push任务就行了，此后线程池当中的线程会从任务队列当中获取到这些任务并进行处理。

#include "Task.hpp"
#include "ThreadPool.hpp"int main()
{srand((unsigned int)time(nullptr));ThreadPool<Task>* tp = new ThreadPool<Task>; //线程池tp->ThreadPoolInit(); //初始化线程池当中的线程const char* op = "+-*/%";//不断往任务队列塞计算任务while (true){sleep(1);int x = rand() % 100;int y = rand() % 100;int index = rand() % 5;Task task(x, y, op[index]);tp->Push(task);}return 0;
}

运行代码后一瞬间就有六个线程，其中一个是主线程，另外五个是线程池内处理任务的线程。

在这里插入图片描述

并且我们会发现这五个线程在处理时会呈现出一定的顺序性，因为主线程是每秒Push一个任务，这五个线程只会有一个线程获取到该任务，其他线程都会在等待队列中进行等待，当该线程处理完任务后就会因为任务队列为空而排到等待队列的最后，当主线程再次Push一个任务后会唤醒等待队列首部的一个线程，这个线程处理完任务后又会排到等待队列的最后，因此这五个线程在处理任务时会呈现出一定的顺序性。

在这里插入图片描述

注意： 此后我们如果想让线程池处理其他不同的任务请求时，我们只需要提供一个任务类，在该任务类当中提供对应的任务处理方法就行了。

二.其他常见的锁

1.STL、智能指针和线程安全

STL中的容器是否是线程安全的? 不是

STL 的设计初衷是将性能挖掘到极致, 而一旦涉及到加锁保证线程安全, 会对性能造成巨大的影响，而且对于不同的容器, 加锁方式的不同, 性能可能也不同(例如hash表的锁表和锁桶).
因此 STL 默认不是线程安全. 如果需要在多线程环境下使用, 往往需要调用者自行保证线程安全。

智能指针是线程安全的吗?

unique_ptr是和资源强关联，只是在当前代码块范围内生效，因此不涉及线程安全问题。
对于 shared_ptr，多个对象需要共有一个引用计数变量，所以会存在线程安全问题。但是标准库实现的时候也考虑到了这个问题，就基于原子操作（Compare And Swap(CAS)）的方式保证 shared_ptr 能够高效原子地操作引用计数。shared_pt 是线程安全的，但不意味着对其管理的资源进行操作是线程安全的，所以对shared_ptr管理的资源进行操作时也可能需要进行加锁保护。

2.其他常见的锁

悲观锁：悲观锁做事比较悲观，它认为多线程同时修改共享资源的概率比较高，于是很容易出现冲突，所以访问贡献资源前，先要进行加锁保护。常见的悲观锁有：互斥锁、自旋锁和读写锁等。
乐观锁：乐观锁做事比较乐观，它乐观地认为共享数据不会被其他线程修改，因此不上锁。它的工作方式是：先修改完共享数据，再判断这段时间内有没有发生冲突。如果其他线程没有修改共享数据，那么则操作成功。如果发现其他线程已经修改该共享数据，就放弃本次操作。乐观锁全程并没有加锁，所以它也叫无锁编程。乐观锁主要采取两种方式：版本号机制（Gitee等）和 CAS 操作。乐观锁虽然去除了加锁和解锁的操作，但是一旦发生冲突，重试的成本是很高的，所以只有在冲突概率非常低，且加锁成本非常高的场景下，才考虑使用乐观锁。
CAS 操作：当需要更新数据时，判断当前内存值和之前取得的值是否相等。如果相等则用新值更新。若不等则失败，失败则重试，一般是一个自旋的过程，即不断重试。
自旋锁：使用自旋锁的时候，当多线程发生竞争锁的情况时，加锁失败的线程会忙等待（这里的忙等待可以用 while 循环等待实现），直到它拿到锁。而互斥锁加锁失败后，线程会让出 CPU 资源给其他线程使用，然后该线程会被阻塞挂起。如果临界区代码执行时间过长，自旋的线程会长时间占用 CPU 资源，所以自旋的时间和临界区代码执行的时间是成正比的关系。如果临界区代码执行的时间很短，就不应该使用互斥锁，而应该选用自旋锁。因为互斥锁加锁失败，是需要发生上下文切换的，如果临界区执行的时间比较短，那可能上下文切换的时间会比临界区代码执行的时间还要长。

三.读者写者问题

1.读者写者模型

在编写多线程的时候，有一种情况是十分常见的。那就是，有些公共数据修改的机会比较少。相比较改写，它们读的机会反而高的多。通常而言，在读的过程中，往往伴随着查找的操作，中间耗时很长。给这种代码段加锁，会极大地降低我们程序的效率。那么有没有一种方法，可以专门处理这种多读少写的情况呢？

这就需要我们的读者写者模型出场了，读者写者模型其实也是维护321原则：

三种关系：读者与读者、读者与写者、写者与写者。
两种对象：读者和写者。
一个交易场所：需要写入和从中读取的缓冲区。

下面我们来看一下读者写者模型的三种关系：

读者与读者：没有关系
读者与写者：互斥与同步
写者与写者：互斥

那么，为什么在生产者消费者模型中，消费者和消费者是互斥关系，而在读者写者问题中，读者和读者之间没有关系呢？

读者写者模型和生产者消费者模型的最大区别就是：消费者会将数据拿走，而读者不会拿走数据，读者仅仅是对数据做读取，并不会进行任何修改的操作，因此共享资源也不会因为有多个读者来读取而导致数据不一致的问题。

2.读写锁

在读者写者模型中，pthread库为我们提供了读写锁来维护其中的同步与互斥关系。读写锁由读锁和写锁两部分构成，如果只读取共享资源用读锁加锁，如果要修改共享资源则用写锁加锁。所以，读写锁适用于能明确区分读操作和写操作的场景。

读写锁的工作原理：

当写锁没有被写线程持有时，多个读线程能够并发地持有读锁，这大大提高了共享资源的访问效率。因为读锁是用于读取共享资源的场景，所以多个线程同时持有读锁也不会破坏共享资源的数据。但是，一旦写锁被写进程持有后，读线程获取读锁的操作会被阻塞，而其它写线程的获取写锁的操作也会被阻塞。

伪代码：

// 写者进程/线程执行的函数
void Writer()
{while(true){P(wCountMutex); // 进入临界区if(wCount == 0)P(rMutex); // 当第一个写者进入，如果有读者则阻塞读者wCount++;// 写者计数 + 1V(wCountMutex); // 离开临界区P(wDataMutex); // 写者写操作之间互斥，进入临界区write(); // 写数据V(wDataMutex); // 离开临界区P(wCountMutex); // 进入临界区wCount--; // 写完数据，准备离开if(wCount == 0){V(rMutex);  // 最后一个写者离开了，则唤醒读者}V(wCountMutex); //离开临界区}
}// 读者进程/线程执行的次数
void reader()
{while(TRUE){P(rMutex);P(rCountMutex); // 进入临界区if ( rCount == 0 )P(wDataMutex); // 当第一个读者进入，如果有写者则阻塞写者写操作rCount++;V(rCountMutex); // 离开临界区V(rMutex);read( ); // 读数据P(rCountMutex); // 进入临界区rCount--;if ( rCount == 0 )V(wDataMutex); // 当没有读者了，则唤醒阻塞中写者的写操作V(rCountMutex); // 离开临界区}
}

在这里插入图片描述
初始化：

int pthread_rwlock_init(pthread_rwlock_t *restrict rwlock,const pthread_rwlockattr_t
*restrict attr);

销毁：

int pthread_rwlock_destroy(pthread_rwlock_t *rwlock);

加锁和解锁：

int pthread_rwlock_rdlock(pthread_rwlock_t *rwlock);
int pthread_rwlock_wrlock(pthread_rwlock_t *rwlock);
int pthread_rwlock_unlock(pthread_rwlock_t *rwlock);