python多线程机制深入理解

今天要跟大家一起来学习一下Python的多线程机制。有两个原因&＃xff0c;其一是自己在学习中经常会使用到多线程&＃xff0c;其二当然是自己对Python中的多线程并不是很了解。那么&＃xff0c;今天和大家一起了解下~

Python多线程机制

开发多线程的应用系统&＃xff0c;是在日常开发中经常会遇到的需求。同时&＃xff0c;Python也为多线程系统的开发提供了很好的支持。
大家应该都知道&＃xff0c;Python多线程机制是在GIL(Global Interpreter Lock)全局解释锁的基础上建立的。

那么Python为什么需要全局解释锁&＃xff1f;

为什么需要全局解释锁&＃xff1f;

我们知道&＃xff0c;要支持多线程的话&＃xff0c;一个基本的要求就是不同线程对共享资源访问的互斥&＃xff0c;所以Python中引入了GIL&＃xff0c;当然这是第一个原因。

Python中的GIL是一个非常霸道的互斥实现&＃xff0c;在一个线程拥有了解释器的访问权之后&＃xff0c;其它的所有线程都必须等待它释放解释器的访问权&＃xff0c;即使这些线程的下一条指令并不会互相影响。

这样的说法也就意味着&＃xff0c;无论如何&＃xff0c;在同一时间&＃xff0c;只能有一个线程能访问Python提供的API。因为单处理器的本质是不可能并行的&＃xff0c;这里的同一时间确实对于单处理器是毫无意义的&＃xff0c;但是对于多处理器&＃xff0c;同一时间&＃xff0c;确实可以有多个时间独立运行。然而正是由于GIL限制了这样的情形&＃xff0c;使得多处理器最终退化为单处理器&＃xff0c;性能大打折扣。那么&＃xff0c;为什么还要使用GIL呢&＃xff1f;这里就要提到第二个原因。

当然&＃xff0c;Python社区也早都认识到了这个问题&＃xff0c;并且在不断探索&＃xff0c;Greg Stein和Mark Hammond两位老兄曾经创建过一份去除GIL的branch&＃xff0c;但是很不幸&＃xff0c;这个分支在很多的基准测试中&＃xff0c;尤其是在单线程的测试上&＃xff0c;效率只有使用GIL的一半左右。

使用GIL时&＃xff0c;保护机制的粒度比较大&＃xff0c;也就是我们似乎只需要将可能被多个线程共享的资源保护起来即可&＃xff0c;对于不会被多个线程共享的资源&＃xff0c;完全可以不用保护。但是&＃xff0c;如果使用更细粒度的锁机制进行保护&＃xff0c;那么&＃xff0c;会导致大量的加锁和解锁功能&＃xff0c;加锁和解锁对于操作系统来说&＃xff0c;是一个比较重量级的动作&＃xff0c;同时&＃xff0c;没有GIL的保护&＃xff0c;编写Python的扩展模块的难度也大大增加。

所以&＃xff0c;目前为止&＃xff0c;GIL仍然是多线程机制的基石。

对于Python而言&＃xff0c;字节码解释器是Python的核心所在&＃xff0c;所以Python通过GIL来互斥不同线程对解释器的使用。这里举个例子进行说明&＃xff1a;

假设&＃xff0c;现在有三个线程A、B和C&＃xff0c;它们都需要解释器来执行字节码&＃xff0c;进行对应的计算&＃xff0c;那么在这之前&＃xff0c;它们必须获得GIL。那么现在假设线程A获得了GIL&＃xff0c;其它线程只能等A释放GIL之后&＃xff0c;才能获得。

对&＃xff01;是这样没错&＃xff0c;于是&＃xff0c;有两个问题&＃xff1a;

1. 线程A何时释放GIL呢&＃xff08;如果A使用完解释器之后才释放GIL&＃xff0c;那么&＃xff0c;并行的计算退化为串行&＃xff0c;多线程的意义何在&＃xff1f;&＃xff09;

2. 线程B和C谁将在A释放GIL之后获得GIL呢&＃xff1f;

所以毫无疑问的&＃xff0c;Python拥有其自己的一套线程调度机制。

关于线程调度

和操作系统的进程调度一样&＃xff0c;线程调度机制主要解决两个问题&＃xff1a;

1. 在何时挂起当前线程&＃xff0c;选择处于等待状态的下一个线程&＃xff1f;

2. 在众多处于等待状态的线程中&＃xff0c;应该选择激活哪个线程&＃xff1f;

对于何时进行线程调度的问题&＃xff0c;是由Python自身决定的。我们可以联想操作系统进行进程切换的问题&＃xff0c;当一个进程执行了一段时间之后&＃xff0c;发生了时钟中断&＃xff0c;于是操作系统响应时钟中断&＃xff0c;并在这时开始进程的调度。

与此类似&＃xff0c;Python中通过软件模拟了这样的中断&＃xff0c;来激活线程的调度。Python的字节码解释器是按照指令的顺序一条一条的顺序执行从而工作的&＃xff0c;Python内部维护着这样一个数值&＃xff0c;作为Python内部的时钟&＃xff0c;假设这个值为N&＃xff0c;那么Python将在执行了N条指令之后立刻启动线程调度机制。

也就是说&＃xff0c;当一个线程获得GIL后&＃xff0c;Python内部的监测机制就开始启动&＃xff0c;当这个线程执行了N条指令后&＃xff0c;Python解释器将强制挂起当前线程&＃xff0c;开始切换到下一个处于等待状态的线程。

在Python中&＃xff0c;可以这样获得这个数值&＃xff08;N&＃xff09;&＃xff1a;

那么&＃xff0c;下一个问题&＃xff0c;Python会在众多等待的线程中选择哪一个呢&＃xff1f;

答案是&＃xff0c;不知道。因为这个问题是交给了底层的操作系统来解决的&＃xff0c;Python借用了底层操作系统所提供的线程调度机制来决定下一个获得GIL进入解释器的线程是谁。

所以说&＃xff0c;Python中的线程实际上就是操作系统所支持的原生线程。

那么&＃xff0c;接下来&＃xff0c;我们一起揭开Python中GIL的真实面目。

关于GIL

应该知道&＃xff0c;Python中多线程常用的两个模块&＃xff1a;Thread和在其之上的threading。其中Thread是使用C实现的&＃xff0c;而Threading是用python实现。

我们可以通过Thread模块进行分析&＃xff08;以Python2.7.13为例&＃xff09;。

创建线程
首先从创建线程说起&＃xff0c;在threadmodule.c中&＃xff0c;thread_PyThread_start_new_thread()函数通过三个主要的动作完成一个线程的创建&＃xff1a;

//创建bootstate结构
boot &＃61; PyMem_NEW(struct bootstate, 1);
if (boot &＃61;&＃61; NULL)
return PyErr_NoMemory();
boot->interp &＃61; PyThreadState_GET()->interp;
boot->func &＃61; func;
boot->args &＃61; args;
boot->keyw &＃61; keyw;
boot->tstate &＃61; _PyThreadState_Prealloc(boot->interp);
if (boot->tstate &＃61;&＃61; NULL) {
PyMem_DEL(boot);
return PyErr_NoMemory();
}
Py_INCREF(func);
Py_INCREF(args);
Py_XINCREF(keyw);
// 初始化多线程环境
PyEval_InitThreads(); 
//创建线程
ident &＃61; PyThread_start_new_thread(t_bootstrap, (void*) boot);
if (ident &＃61;&＃61; -1) {
PyErr_SetString(ThreadError, "can&＃39;t start new thread");
Py_DECREF(func);
Py_DECREF(args);
Py_XDECREF(keyw);
PyThreadState_Clear(boot->tstate);
PyMem_DEL(boot);
return NULL;
}
return PyInt_FromLong(ident);

1. 创建并初始化bootstate结构boot&＃xff0c;在boot中&＃xff0c;将保存关于Python的一切信息&＃xff08;线程过程&＃xff0c;线程过程参数等)。

2. 初始化Python的多线程环境。

3. 以boot为参数&＃xff0c;创建操作系统的原生线程。

从以上代码可以看出&＃xff0c;Python在刚启动时&＃xff0c;并不支持多线程&＃xff0c;也就是说&＃xff0c;Python中支持多线程的数据结构以及GIL都是没有创建的。当然这是因为大多数的Python程序都不需要Python的支持。

在Python虚拟机启动时&＃xff0c;多线程机制并没有被激活&＃xff0c;它只支持单线程&＃xff0c;一旦用户调用thread.start_new_thread&＃xff0c;明确的告诉Python虚拟机需要创建新的线程&＃xff0c;这时Python意识到用户需要多线程的支持&＃xff0c;这个时候&＃xff0c;Python虚拟机会自动建立多线程需要的数据结构、环境以及GIL。

建立多线程环境

建立多线程环境&＃xff0c;主要就是创建GIL。那么GIL是如何实现的呢&＃xff1f;
打开"python/ceval.c"&＃xff1a;

static PyThread_type_lock interpreter_lock &＃61; 0; /* This is the GIL */
static PyThread_type_lock pending_lock &＃61; 0; /* for pending calls */
static long main_thread &＃61; 0;

int
PyEval_ThreadsInitialized(void)
{
return interpreter_lock !&＃61; 0;
}

void
PyEval_InitThreads(void)
{
if (interpreter_lock)
return;
interpreter_lock &＃61; PyThread_allocate_lock();
PyThread_acquire_lock(interpreter_lock, 1);
main_thread &＃61; PyThread_get_thread_ident();
}

在这段代码中&＃xff0c;iterpreter_lock就是GIL。

无论创建多少个线程&＃xff0c;Python建立多线程环境的动作只会执行一次。在创建GIL之前&＃xff0c;Python会检查GIL是否已经被创建&＃xff0c;如果是&＃xff0c;则不再进行任何动作&＃xff0c;否则&＃xff0c;就会去创建这个GIL。

在上述代码中&＃xff0c;我们可以看到&＃xff0c;创建GIL使用的是Pythread_allocate_lock完成的&＃xff0c;下面看看该函数的内部实现&＃xff1a;

PyThread_type_lock
PyThread_allocate_lock(void)
{
PNRMUTEX aLock;

dprintf(("PyThread_allocate_lock called\n"));
if (!initialized)
PyThread_init_thread();

aLock &＃61; AllocNonRecursiveMutex() ;

dprintf(("%ld: PyThread_allocate_lock() -> %p\n", PyThread_get_thread_ident(), aLock));

return (PyThread_type_lock) aLock;
}

可以看到该函数返回了alock&＃xff0c;alock是结构体PNRMUTEX&＃xff0c;实际上就是我们需要创建的那个interperter_lock(GIL&＃xff09;。这么说来&＃xff0c;GIL就是结构体PNRMUTEX呀&＃xff0c;于是我们找来它的真身&＃xff1a;

typedef struct NRMUTEX {
LONG owned ;
DWORD thread_id ;
HANDLE hevent ;
} NRMUTEX, *PNRMUTEX ;

这里又三个变量&＃xff0c;owned、thread_id和hevent。这里的hevent是windows平台下的Event这个内核对象&＃xff0c;也就是通过Event来实现线程之间的互斥。thread_id将记录任一时刻获得GIL的线程的id。

那么owned是什么呢&＃xff1f;

GIL中的owned是指示GIL是否可用的变量&＃xff0c;它的值被初始化为-1&＃xff0c;Python会检查这个值是否为1&＃xff0c;如果是&＃xff0c;则意味着GIL可用&＃xff0c;必须将其置为0&＃xff0c;当owned为0后&＃xff0c;表示该GIL已经被一个线程占用&＃xff0c;不可再用&＃xff1b;同时&＃xff0c;当一个线程开始等待GIL时&＃xff0c;其owned就会被增加1&＃xff1b;当一个线程最终释放GIL时&＃xff0c;一定会将GIL的owned减1&＃xff0c;这样&＃xff0c;当所有需要GIL的线程都最终释放了GIL之后&＃xff0c;owned将再次变为-1&＃xff0c;意味着GIL再次变为可用。

关于Python中的多线程&＃xff0c;今天我们就学到这里。