PyEval_InitThreads в Python 3: как и когда его вызывать? (сага продолжается до тошноты)

Вы правильно поняли: вызов PyEval_InitThreads, среди прочего, получает GIL. В правильно написанном приложении Python/C это не проблема, потому что GIL будет разблокирован вовремя, либо автоматически, либо вручную.

Если основной поток продолжает выполнять код Python, делать особо нечего, потому что интерпретатор Python автоматически откажется от GIL после выполнения ряда инструкций (позволив другому потоку получить его, который снова откажется от него, и так далее). на). Кроме того, всякий раз, когда Python собирается вызвать блокирующий системный вызов, например. для чтения из сети или записи в файл, он освобождает GIL вокруг вызова.

Первоначальная версия этого ответа в значительной степени закончилась здесь. Но есть еще одна вещь, которую следует учитывать: сценарий встраивания.

При встраивании Python основной поток часто инициализирует Python и продолжает выполнять другие задачи, не связанные с Python. В этом сценарии нет ничего, что могло бы автоматически освободить GIL, поэтому это должен сделать сам поток. Это никоим образом не относится к вызову, который вызывает PyEval_InitThreads, он ожидается от весь код Python/C, вызванный с помощью полученного GIL.

Например, main() может содержать такой код:

Py_Initialize();
PyEval_InitThreads();

Py_BEGIN_ALLOW_THREADS
... call the non-Python part of the application here ...
Py_END_ALLOW_THREADS

Py_Finalize();

Если ваш код создает потоки вручную, им необходимо получить GIL, прежде чем делать все, связанные с Python, даже такие простые, как Py_INCREF. Для этого используйте следующее :

// Acquire the GIL
PyGILState_STATE gstate;
gstate = PyGILState_Ensure();

... call Python code here ...

// Release the GIL. No Python API allowed beyond this point.
PyGILState_Release(gstate);

Я видел симптомы, похожие на ваши: взаимоблокировки, если я вызываю только PyEval_InitThreads(), потому что мой основной поток больше никогда ничего не вызывает из Python, и segfaults, если я безоговорочно вызываю что-то вроде PyEval_SaveThread(). Симптомы зависят от версии Python и от ситуации: я разрабатываю подключаемый модуль, который встраивает Python для библиотеки, которую можно загрузить как часть расширения Python. Поэтому код должен работать независимо от того, загружен ли он Python как основной.

Следующее работало как с python2.7, так и с python3.4, а также с моей библиотекой, работающей в Python и вне Python. В моей подпрограмме инициализации плагина, которая выполняется в основном потоке, я запускаю:

  Py_InitializeEx(0);
  if (!PyEval_ThreadsInitialized()) {
    PyEval_InitThreads();
    PyThreadState* mainPyThread = PyEval_SaveThread();
  }

(mainPyThread на самом деле является некоторой статической переменной, но я не думаю, что это имеет значение, поскольку мне больше никогда не понадобится ее использовать).

Затем я создаю потоки, используя pthreads, и в каждой функции, которой требуется доступ к Python API, я использую:

  PyGILState_STATE gstate;
  gstate = PyGILState_Ensure();
  // Python C API calls
  PyGILState_Release(gstate);

Существует два метода многопоточности при выполнении C/Python API.

1. Выполнение разных потоков с одним и тем же интерпретатором. Мы можем выполнить интерпретатор Python и использовать один и тот же интерпретатор в разных потоках.

Кодирование будет следующим.

main(){     
//initialize Python
Py_Initialize();
PyRun_SimpleString("from time import time,ctime\n"
    "print 'In Main, Today is',ctime(time())\n");

//to Initialize and acquire the global interpreter lock
PyEval_InitThreads();

//release the lock  
PyThreadState *_save;
_save = PyEval_SaveThread();

// Create threads.
for (int i = 0; i<MAX_THREADS; i++)
{   
    hThreadArray[i] = CreateThread
    //(...
        MyThreadFunction,       // thread function name
    //...)

} // End of main thread creation loop.

// Wait until all threads have terminated.
//...
//Close all thread handles and free memory allocations.
//...

//end python here
//but need to check for GIL here too
PyEval_RestoreThread(_save);
Py_Finalize();
return 0;
}

//the thread function

DWORD WINAPI MyThreadFunction(LPVOID lpParam)
{
//non Pythonic activity
//...

//check for the state of Python GIL
PyGILState_STATE gilState;
gilState = PyGILState_Ensure();
//execute Python here
PyRun_SimpleString("from time import time,ctime\n"
    "print 'In Thread Today is',ctime(time())\n");
//release the GIL           
PyGILState_Release(gilState);   

//other non Pythonic activity
//...
return 0;
}

2. Другой метод заключается в том, что мы можем выполнять интерпретатор Python в основном потоке, и каждому потоку мы можем дать свой собственный интерпретатор. Таким образом, каждый поток работает со своими отдельными независимыми версиями всех импортированных модулей, включая основные модули — встроенные модули, __main__ и sys.

Код выглядит следующим образом

int main()
{

// Initialize the main interpreter
Py_Initialize();
// Initialize and acquire the global interpreter lock
PyEval_InitThreads();
// Release the lock     
PyThreadState *_save;
_save = PyEval_SaveThread();


// create threads
for (int i = 0; i<MAX_THREADS; i++)
{

    // Create the thread to begin execution on its own.

    hThreadArray[i] = CreateThread
    //(...

        MyThreadFunction,       // thread function name
    //...);   // returns the thread identifier 

} // End of main thread creation loop.

  // Wait until all threads have terminated.
WaitForMultipleObjects(MAX_THREADS, hThreadArray, TRUE, INFINITE);

// Close all thread handles and free memory allocations.
// ...


//end python here
//but need to check for GIL here too
//re capture the lock
PyEval_RestoreThread(_save);
//end python interpreter
Py_Finalize();
return 0;
}

//the thread functions
DWORD WINAPI MyThreadFunction(LPVOID lpParam)
{
// Non Pythonic activity
// ...

//create a new interpreter
PyEval_AcquireLock(); // acquire lock on the GIL
PyThreadState* pThreadState = Py_NewInterpreter();
assert(pThreadState != NULL); // check for failure
PyEval_ReleaseThread(pThreadState); // release the GIL


// switch in current interpreter
PyEval_AcquireThread(pThreadState);

//execute python code
PyRun_SimpleString("from time import time,ctime\n" "print\n"
    "print 'Today is',ctime(time())\n");

// release current interpreter
PyEval_ReleaseThread(pThreadState);

//now to end the interpreter
PyEval_AcquireThread(pThreadState); // lock the GIL
Py_EndInterpreter(pThreadState);
PyEval_ReleaseLock(); // release the GIL

// Other non Pythonic activity
return 0;
}

Необходимо отметить, что глобальная блокировка интерпретатора по-прежнему сохраняется, и, несмотря на предоставление отдельных интерпретаторов каждому потоку, когда дело доходит до выполнения Python, мы по-прежнему можем выполнять только один поток за раз. GIL является УНИКАЛЬНЫМ для PROCESS, поэтому, несмотря на предоставление уникального подинтерпретатора для каждого потока, мы не можем иметь одновременное выполнение потоков

Источники: Выполнение интерпретатора Python в основной поток, и каждому потоку мы можем дать свой собственный интерпретатор

Учебное пособие по многопоточности (msdn)

Чтобы процитировать выше:

Короткий ответ: вам не нужно выпускать GIL после вызова PyEval_InitThreads...

Теперь более развернутый ответ:

Я ограничиваю свой ответ тем, что он касается расширений Python (в отличие от встраивания Python). Если мы расширяем только Python, то любая точка входа в ваш модуль исходит из Python. Это по определению означает, что нам не нужно беспокоиться о вызове функции из контекста, отличного от Python, что немного упрощает задачу.

Если потоки НЕ были инициализированы, то мы знаем, что нет GIL (нет потоков == нет необходимости в блокировке), и, следовательно, «небезопасно вызывать эту функцию, когда неизвестно, какой поток (если есть) в настоящее время имеет глобальный блокировка интерпретатора" не применяется.

if (!PyEval_ThreadsInitialized())
{
    PyEval_InitThreads();
}

После вызова PyEval_InitThreads() создается GIL и назначается... нашему потоку, который в настоящее время выполняет код Python. Так что все хорошо.

Теперь, что касается наших собственных запущенных рабочих «C»-потоков, им нужно будет запрашивать GIL перед запуском соответствующего кода: поэтому их общая методология выглядит следующим образом:

// Do only non-Python things up to this point
PyGILState_STATE state = PyGILState_Ensure();
// Do Python-things here, like PyRun_SimpleString(...)
PyGILState_Release(state);
// ... and now back to doing only non-Python things

Нам не нужно беспокоиться о тупиковой ситуации больше, чем об обычном использовании расширений. Когда мы вошли в нашу функцию, у нас был контроль над Python, поэтому либо мы не использовали потоки (таким образом, без GIL), либо GIL уже был нам назначен. Когда мы вернем управление среде выполнения Python, выйдя из нашей функции, обычный цикл обработки проверит GIL и передаст управление другим запрашивающим объектам, включая наши рабочие потоки через PyGILState_Ensure().

Все это читатель наверняка уже знает. Однако «доказательство в пудинге». Я опубликовал очень минимально документированный пример, который я написал сегодня, чтобы узнать для себя, что на самом деле было поведением, и что все работает правильно. Пример исходного кода на GitHub

На этом примере я узнал несколько вещей, в том числе интеграцию CMake с разработкой Python, интеграцию SWIG с обоими вышеперечисленными и поведение Python с расширениями и потоками. Тем не менее, ядро ​​примера позволяет вам:

• Загрузите модуль -- 'импорт раздражает'
• Загрузить ноль или более рабочих потоков, которые выполняют функции Python — 'annoy.annoy(n)'
• Очистить все рабочие потоки -- 'annon.annoy(0)'
• Обеспечить очистку потока (в Linux) при выходе из приложения

... и все это без каких-либо сбоев или ошибок. По крайней мере, в моей системе (Ubuntu Linux с GCC).

Предложение вызвать PyEval_SaveThread работает

PyEval_InitThreads();
PyThreadState* st = PyEval_SaveThread();

Однако, чтобы предотвратить сбой при импорте модуля, убедитесь, что API-интерфейсы Python для импорта защищены с помощью

PyGILState_Ensure и PyGILState_Release

e.g.

PyGILState_STATE gstate = PyGILState_Ensure();
PyObject *pyModule_p = PyImport_Import(pyModuleName_p);
PyGILState_Release(gstate);

Я тоже чувствую замешательство в этом вопросе. Следующий код работает по совпадению.

Py_InitializeEx(0);
    if (!PyEval_ThreadsInitialized()) {
    PyEval_InitThreads();
    PyThreadState* mainPyThread = PyEval_SaveThread();
}

Мой основной поток выполняет некоторую начальную работу во время выполнения Python и создает другой поток для обработки задач. И у меня есть лучший обходной путь для этого. В основной теме:

if (!PyEval_ThreadsInitialized()){
    PyEval_InitThreads();
}
//other codes
while(alive) {
    Py_BEGIN_ALLOW_THREADS
    sleep or other block code
    Py_END_ALLOW_THREADS
}

Вам не нужно вызывать это в своих модулях extension. Это для инициализации интерпретатора, которая уже была выполнена, если ваш модуль расширения C-API импортируется. Этот интерфейс предназначен для встраивания приложений.

Когда должен вызываться PyEval_InitThreads?

Эта функция устарела в Python 3.9: https://docs.python.org/3/c-api/init.html#c.PyEval_InitThreads

Начиная с Python 3.7 функция уже вызывается Py_Initialize().

Начиная с Python 3.9 функция ничего не делает.

В Python 3.11 он будет удален.