Python の GIS とスレッドを説明するさまざまな記事を読んだ後、GIL のためにマルチスレッドの Python コードではロックは不要ですか? これは非常に役立つ回答です。「最後の質問」が 1 つあります。
理想的には、スレッドがアトミック (Python VM) 命令を介して共有データのみを操作する場合、たとえば、リストにアイテムを追加する場合、ロックは必要ありませんよね?
Python の GIS とスレッドを説明するさまざまな記事を読んだ後、GIL のためにマルチスレッドの Python コードではロックは不要ですか? これは非常に役立つ回答です。「最後の質問」が 1 つあります。
理想的には、スレッドがアトミック (Python VM) 命令を介して共有データのみを操作する場合、たとえば、リストにアイテムを追加する場合、ロックは必要ありませんよね?
それは本当にあなたのアプリケーションに依存します。他の言語と同じように、特定のユースケースではロックが必要になる場合がありますが、Python オブジェクトが壊れないように保護する必要はありません。そういう意味では、ロックは必要ありません。
これは、かなりアトミックな操作の束を使用する例ですが、それらを組み合わせると、予期しない方法で動作する可能性があります。
スレッド 1:
v = l[-1]
DoWork(v]
del l[-1]
スレッド 2:
l.append(3)
スレッド 2 がスレッド 1 の最初と最後のステートメントの間で実行される場合、スレッド 1 は間違った作業項目を削除しただけです。どの Python オブジェクトも破損していませんが、それでも予期しない結果が得られ、例外がスローされる可能性があります。
データ構造を共有している場合は、通常、それらをロックで保護する必要があります。または、この場合はおそらくキューのように、既に作成された保護されたバージョンを使用することをお勧めします: http://docs.python.org/library/queue.html
答えてくれてありがとう!スレッド同期要件がアプリケーションロジックにバインドされていることは明らかですが、組み込みオブジェクトの内部を破損しないようにGILに依存できます(操作はアトミックです)。インタプリタの「内部状態」、その内部データ構造を保護すると言ったとき、私にはわかりませんでした...つまり、これは効果ですが、GILは、オブジェクトの両方に対して、割り当てられたすべての組み込み構造を保護しますインタプリタの内部操作およびアプリケーションによって作成されたオブジェクトによって作成および使用されます。それは私の疑問でした。
PS:回答が遅くなってすみませんが、通知メールが届きませんでした...
スレッド間でデータを共有する場合は、操作が将来アトミックになるかどうかに依存できないため、データが適切に同期されていることを常に確認する必要があります。
実装の変更や間違った仮定のために機能しなくなったものを修正しようとするよりも、最初からマルチスレッド設計を正しく行う方が簡単です。