3

私はPySide/Cythonマルチスレッド アプリケーションで何日も苦労してきました。
問題をいくつかの部分に分けて、valgrind/helgrind で実行するテストに入りました (以下の 1 つのエラー エントリを参照)。
C 関数 (load以下の CHLone) は Python をその GIL (Cython へのディレクティブなし) で使用し、 Shibokenも GIL にアクセスします。
出力は、GILアクセスとの競合があることを示唆していますが（私が間違っていない限り）、GILはそのような競合を回避するために存在したと理解しています。

Shibokenは、他のスレッドの と衝突するいくつかの dealloc を実行しPyList_Newます...

別のスレッドがいくつかの Python 共有データを変更している間、GIL がブロックを担当している
と思っていました。それともシボケンがロックし忘れ？ PyList_New

listobject.c行 161 は、新しいオブジェクトを追跡するように GC に要求する (私が推測する) 呼び出しです_PyObject_GC_TRACK()。行 2360 は、GC にオブジェクトの追跡を停止するように要求しているように見える呼び出し
です ... helgrind diagはデータ競合の可能性があることがわかりますが、実際のところ、これはコア ダンプにつながり、私は好きではありませんスレッドの使用中に Python GC でその可能性のある単語。まずはここを直したい。classobject.c_PyObject_GC_UNTRACK()

==26535== ----------------------------------------------------------------
==26535== 
==26535== Possible data race during read of size 8 at 0x4FE8488 by thread #2
==26535== Locks held: none
==26535==    at 0x4C92A80: PyList_New (listobject.c:161)
==26535==    by 0x742C43F: s2p_parseAndReadHDF (SIDStoPython.c:949)
==26535==    by 0x742C5C4: s2p_parseAndReadHDF (SIDStoPython.c:968)
==26535==    by 0x742E638: s2p_loadAsHDF (SIDStoPython.c:1485)
==26535==    by 0x741C3CC: __pyx_f_6CHLone_load (pyCHLone.c:2182)
==26535==    by 0x741D2AD: __pyx_pf_6CHLone_12load (pyCHLone.c:2422)
==26535==    by 0x741D1C3: __pyx_pw_6CHLone_13load (pyCHLone.c:2392)
==26535==    by 0x4D0A48F: PyEval_EvalFrameEx (ceval.c:4013)
==26535==    by 0x4D0C3DC: PyEval_EvalCodeEx (ceval.c:3253)
==26535==    by 0x4C8B641: function_call (funcobject.c:526)
==26535==    by 0x4C5F652: PyObject_Call (abstract.c:2529)
==26535==    by 0x4C7279E: instancemethod_call (classobject.c:2578)
==26535== 
==26535== This conflicts with a previous write of size 8 by thread #1
==26535== Locks held: none
==26535==    at 0x4C6C53F: instancemethod_dealloc (classobject.c:2360)
==26535==    by 0x5AB248A: Shiboken::AutoDecRef::~AutoDecRef() (in /tmp/tools-2/local/x86z/lib/python2.7/site-packages/PySide/QtCore.so)
==26535==    by 0x5F9736F: PySide::GlobalReceiverV2::qt_metacall(QMetaObject::Call, int, void**) (in /tmp/tools-2/local/x86z/lib/libpyside-python2.7.so.1.0.9)
==26535==    by 0x659BCA5: QObject::event(QEvent*) (in /tmp/tools-2/local/x86z/lib/libQtCore.so.4.8.0)
==26535==    by 0x5B038C5: QCoreApplicationWrapper::notify(QObject*, QEvent*) (in /tmp/tools-2/local/x86z/lib/python2.7/site-packages/PySide/QtCore.so)
==26535==    by 0x6586F8B: QCoreApplication::notifyInternal(QObject*, QEvent*) (in /tmp/tools-2/local/x86z/lib/libQtCore.so.4.8.0)
==26535==    by 0x658A5A7: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (in /tmp/tools-2/local/x86z/lib/libQtCore.so.4.8.0)
==26535==    by 0x65B60F2: ??? (in /tmp/tools-2/local/x86z/lib/libQtCore.so.4.8.0)
==26535==

質問:
1. GIL に対して想定している動作は正しいですか?
2. Noの場合
... 各スレッドの GIL ロックを自分で管理する必要があるということですか?
... 次に、Python 用に独自のミューテックスを作成する必要がありますか?!??!?
3.はいの場合
... GIL の使用に関して、私の Cython または C ライブラリに問題はありますか?
... QThread/QMutexの副作用でしょうか?

4

1 に答える 1

2

CPython では、グローバル インタープリター ロック (GIL) は、複数のネイティブ スレッドが Python バイトコードを一度に実行するのを防ぐミューテックスです。

したがって、GIL に期待できるのは、Python コードの 2 つのストリームが同時に実行されないようにすることだけです。それ以上のロック動作は期待しないでください。一般に、保護されている GIL に依存するコードを書くことは悪い習慣です。GIL は、多くの人が削除したいいぼであり、IronPython や jython などの一部の形式の Python には存在しません。それが存在する場合、同時実行性が低下し、オーバーヘッドが発生し、Python コードがそうでない場合よりも推論が難しくなります。

上記から、GILの障害が関係していることは明らかではありません。2 番目のトレースは、GIL が制限していると私が理解している領域ではなく、c++ の領域に深く関わっているようです。

于 2013-06-12T18:34:39.210 に答える