通过C/C++扩展的方式在Python中进行并发

这段时间一直被Python下的多线程所困扰，很是不爽，不过虽然很早就知道了GIL这个东西的存在，却依然不信邪，在想会不会有什么办法可以绕过它，经过一段时间的苦逼尝试后，总算想到了一个曲线救国的方法，今天就来详细介绍一下。

小故事

首先简单回顾一下我们常说的Python多线程蛋疼之处，这里用一个简单例子来进行介绍：

from multiprocessing.dummy import Pool

def cpu_fun(arg):
    K = 1000
    while K>0:
        i = 3000
        while i>0:
            i -= 1
        K -= 1

pool = Pool(4)
pool.map(cpu_fun, range(20))

如果问一个不知道GIL存在的Python初学者上述代码在一个CPU核心数非常大（比如128）的服务器上运行会占用多少CPU资源，他大概会先去查一下这个multiprocessing.dummy.Pool是什么东西，然后在了解到这是线程池之后回答“CPU占用率400%！”，然而非常不幸的是，它实际运行起来一般只能达到160-190%的占用率，即使你把Pool的参数从4调成8甚至100也没用，这时，你就可以开始以一副长者的姿态告诉他关于GIL的种种概念。

那么现在让我们换一段代码，

import cv2
import numpy as np
from multiprocessing.dummy import Pool

def cpu_fun(arg):
    S = 700
    x = np.random.uniform(0, 1, (S, S))
    y = cv2.SVDecomp(x)
    return y

pool = Pool(4)
pool.map(cpu_fun, range(20))

此时Python初学者的心理活动大概是：“尼玛，这不是和上面的差不多么？等等，这里的cpu_fun里面调用了OpenCV的SVD操作，这一定是个坑！”，然后回答说“考虑到OpenCV的SVD操作有可能是多线程实现的，假设其每次会调用M个线程进行计算，那么CPU占用率应该是上面160-190%的M倍。”那么我们运行一下看看，“卧槽，居然是400%！怎么GIL没用了。。。不可能，一定是M乘以160-190%后正好等于400%左右，请你把线程数调成16！”，OK，调整后再运行，“卧槽，居然是1600%！难道是GIL只限制纯粹的C代码？好像WIKI确实有这么写，GIL是用来限制pure python code的，这次一定是这个原因。”那我们现在把上面调用的SVD分解换成一个用C实现的循环Loop看看，

#include <Python.h>

static int test(int arg) {
    int i = 2000;
    while(i>0) {
        i--;
        int j = 2000;
        while(j>0) {
            j--;
            int k=2000;
            while(k>0) k--;
        }
    }
    return arg;
}

PyObject * _test(PyObject *self, PyObject *args) {
    int arg;
    if(!PyArg_ParseTuple(args, "i", &arg));
    int ret = test(arg);
    PyObject *obj;
    obj = Py_BuildValue("i", ret);
    return obj;
}

/* Method list */
static PyMethodDef CalMethods[] = {
    {"test", _test, METH_VARARGS, "compute."},
    {NULL, NULL, 0, NULL}
};

/* Initialization function */
PyMODINIT_FUNC
initcalculate(void) {
    PyObject *m;
    m = Py_InitModule("calculate", CalMethods);
    if(m == NULL) {
        return;
    }
}

Python初学者：“这次调用的还是C实现的代码，所以多线程并发应该没有问题，占用率是1600%。”，运行，CPU占用100%，Python初学者卒。

小故事的答案

那么上面第二段代码为什么在更改一个CPU计算函数后就能够正常的并发了呢，而第三段代码又为什么不能够并发？答案是既然Python有GIL可以把多线程锁住，那么也一定有办法把这个GIL打开！

经常有人告诉我们Python可以调用C/C++的扩展来对计算密集型的模块进行加速，但是这里的原因除去一般人所知道的Python语言本身速度慢（例如loop特别慢），还有一点就是在C/C++中我们可以有办法执行真正的多线程并发，官方WIKI说只要在调用函数首尾加两个神奇的宏：

#include "Python.h"
...

PyObject *pyfunc(PyObject *self, PyObject *args) {
   ...
   Py_BEGIN_ALLOW_THREADS
   // Threaded C code
   ...
   Py_END_ALLOW_THREADS
   ...
}

boost.python的WIKI上提供了一个更好的遵循”Resource Acquisition Is Initialization”原则的方法，就是定义一个变量，让其在创建时释放GIL，析构时重新上锁，用户不需要手动进行操作，另外在Python的C API文档里有提到Py_BEGIN_ALLOW_THREADS实际上会被展开为

{ PyThreadState *_save; _save = PyEval_SaveThread();

而Py_END_ALLOW_THREADS会被展开为

PyEval_RestoreThread(_save); }

因此上述方法可以用下面的代码进行表示

class ScopedGILRelease {
public:
    inline ScopedGILRelease() {
        m_thread_state = PyEval_SaveThread();
    }

    inline ~ScopedGILRelease() {
        PyEval_RestoreThread(m_thread_state);
        m_thread_state = NULL;
    }
private:
    PyThreadState * m_thread_state;
};

然后在你的C函数加上一个wrapper

int foo_wrapper(int x) {
    ScopedGILRelease scoped;
    return foo(x);
}

亲测上述方法有效，可以让上面第三段代码也实现正常并发。不过如果你不是手写这种很底层的接口代码，而是调用boost.python或者ctypes之类的已有框架，它们一般都会自动帮你在自定义函数首尾执行这两个宏，让你完全忽略Python GIL的存在！

通过C/C++扩展的方式在Python中进行并发计算

看起来这篇文章到上面一节就已经可以结束了，毕竟此篇不负责介绍如何在Python中调用C/C++的模块，而我们也已经知道Python可以通过调用C/C++代码的方式进行并发计算，现在还需要介绍什么呢？答案是对于不同种类的并发程序，我们还得在C/C++代码中有不同的实现方式，这里主要介绍两类常见的并发任务：

同步任务：并发只存在于任务函数内部，在函数返回后不再占用任何资源；
异步任务：即使任务函数返回，程序回到Python主线程后，后台仍有继续运行的后台并发线程（例如任务队列）。

对于同步任务类型，使用起来非常简单，类似于上面的ret_list = pool.map(fun, arg_list)，在程序并发执行这些任务时，Python主线程被阻塞，直到所有的任务线程返回，上面第二段代码实际上就是一个标准的同步任务类型。

对于异步任务类型，稍微有些不一样，通常在使用时的代码如下：

for i in range(task_num):
    submit_task(i)

do_something()

for i in range(task_num):
    fetch_result(i)

即在Python主线程中先把所有任务提交，提交时主线程不会被阻塞，可以继续执行一些代码，然后最后根据需要获取后台线程的结果。注意，此时由于提交任务后主线程不被阻塞，因此如果GIL被释放后没有重新上锁的话，所有的线程（不管C线程还是Python线程）都是可以并发运行的。

看起来Python并发的问题已经完全被解决了呢！不过等等，如果真的可以这么解决，那GIL是不是有点太容易被绕过了？或者说如果这样就解决了的话，GIL存在的意义是啥？

在Python的官方WIKI上我们可以看到这样一段话：

“In CPython, the global interpreter lock, or GIL, is a mutex that prevents multiple native threads from executing Python bytecodes at once. This lock is necessary mainly because CPython’s memory management is not thread-safe. ”

意思是Python内部的内存管理不是线程安全的，因此必须得有GIL保证不会有多个Python对其竞争访问。现在回想一下刚才介绍的两种任务类型，对于同步任务类型而言，并发线程都在C/C++代码里实现，而且并发的时候Python主线程也是阻塞住的，所以确实不会有任何问题；但是对于异步任务类型，由于Python主线程和C/C++的后台线程都是同时运行，因此Python的内存访问是存在一定风险的，我们无法保证所有线程都可以安全的访问内存地址（除非C/C++线程不会与任何Python对象打交道）！

好吧，看来用C/C++来实现多线程任务队列的计划必须非常小心，否则很有可能跑着跑着出现memory的问题，不过问题来了，听说TensorFlow的任务队列是可以做到异步并行的，它是如何避免上述问题的呢？。。。你们谁知道答案快点告诉我。。。

小故事

小故事的答案

通过C/C++扩展的方式在Python中进行并发计算

nicklhy