問題タブ [green-threads]

私の知る限り、Python では、マルチコア環境で通常のスレッドを使用すると、通常、GIL が途中で発生し、パフォーマンスに悪影響を及ぼします (スレッドが GIL を常に取得および解放しようとし、スレッド/プロセッサ間の多くのコンテキスト切り替え)。

そのため、多くの人がグリーン スレッド (eventlet など) を使い始めています。イベントレット ライブラリを使用すると、複数のグリーン スレッドを協調して動作させることができ、単一のプロセッサで完全に動作します (同期の問題が少なく、迅速な生成/効率など)。

私の質問は、マルチコア OS を使用していて、Python アプリケーションを設計する場合、協調スレッド (グリーン スレッド) とマルチコア プロセッサの両方を利用するために従うべきベスト プラクティスまたは設計パターンは何かということです。

Rails アプリケーションへのリクエストが Phusion Passenger でどのように処理されるかを正確に理解しようとしています。Passenger のドキュメント (ここにあります: http://www.modrails.com/documentation/Architectural%20overview.html#_phusion_passenger_architecture ) を読み、Rails フレームワークとアプリケーション コードのコピーをメモリに保持する方法を理解しました。アプリケーションへのすべてのリクエストが、アプリケーションの別のインスタンスをスピンアップすることによって行き詰まることはありません。私が理解できないのは、これらの個別のアプリケーション インスタンスが私の Linux マシンでネイティブの Ruby プロセスを共有する方法です。私はいくつかの調査を行ってきましたが、ここで私が考えていることは次のとおりです。

1 つの要求が Web サーバーにヒットし、Web サーバーが Passenger をディスパッチして、Passenger のアイドル状態のワーカー プロセスの 1 つで要求を実行します。別の要求がほぼ同時に受信され、さらに別のアイドル状態の Passenger ワーカー プロセスによって処理されます。

この時点で、2 つの異なる Passenger ワーカー プロセスによって管理されている 2 つの要求が実行されています。Passenger は、ワーカー プロセスごとに Linux のネイティブ Ruby スレッド上にグリーン スレッドを作成します。各グリーン スレッドは、コンテキスト切り替えを使用して実行されるため、1 つの Passenger ワーカー プロセスで操作がブロックされても、他のワーカー プロセスの実行が妨げられることはありません。

私は正しい軌道に乗っていますか？

ご協力いただきありがとうございます！

アセンブリにグリーン スレッド/プロセスを実装しようとしています。

たとえば、この x64 アセンブリ コード (nasm 構文) には 2 つのループがあります。'a'がたくさん出力されますが、'a'と'b'を出力してほしいです。2 つのループを組み合わせるだけで問題が解決するため、これはもちろん実際の例ではありません。

したがって、いくつかのレジスタを保存し、スタックポインタを変更しながら、命令ポインタをmain.t1または数マイクロ秒ごとに変更するある種のスケジューラを書きたいと思います。main.t2

これがユーザー空間で不可能である場合は理解していますが、プロセスが実行中のプログラムを変更できる可能性は非常に低いと思われます。ユーザー空間からできない場合、カーネルモジュールで可能でしょうか?

通常の python スレッドと greenthread (eventlet) での動作にthreading.Lock()違いはありますか?threading.Semaphore()

以下のコードを書きましたが、killThreadブロックとスレッドがまだ継続していることに気付きました。これは、forkProcess で実行した場合にのみ発生し、forkProcess を削除すると、すべてが期待どおりに機能します。

コード

出力

これは、メモリ割り当てがないために GHC のスレッド スケジューラが実行されないという通常の問題ではありません。でプログラムを実行して確認しましたが+RTS -sstderr、これはガベージ コレクターが非常に頻繁に実行されていることを示しています。これをLinux 64ビットで実行しています。

Stackless Python のタスクレットについて、Google で大規模な調査を行いました。すべての情報源はそれをスレッドとして言及しています

stackless.com : マイクロスレッド: タスクレットは関数をラップして、マイクロスレッドとして起動できるようにします。

disinterest.orgv: タスクレット — 軽量スレッド

ただし、タスクレットは同時実行ではありません。コードの一部を実行します。

次のようなコード:

印刷します

タスクレットは、stackless.schedule() に遭遇するまでコードを実行し、その後、最初または最後の一時停止の場所から次のタスクレットを実行します。

すべてのプログラマーは、「GOTO を使用しない」という黄金律を知っています。私の質問は次のとおりです。

GOTOとどう違うの？
タスクレットが並列実行されていない場合、タスクレットを使用する利点は何ですか?
それらが実際にはスレッドではないのに、なぜすべてのソースがそれらをスレッドの代替として言及しているのですか?

Python のグリーン スレッドには、ジョブを完了するための協調的なマルチタスキングがあります。次のシナリオで使用する必要があります。これは、他のスレッドに制御を譲ったり渡したりしないためです。

シナリオ：

ブロッキング機能のコマンドは 1 つだけです。それは、別のマシンへの長時間実行される SSH です。したがって、複数のグリーンスレッドがある場合でも、最初のスレッドが接続を開始するために次のスレッドに制御を渡さないため、複数の SSH 接続が開かない可能性もあります。

マシン上でその SSH を介してインストールが行われます。

イベントレットのグリーンスレッドでサーバーを実行し、すべてにモンキーパッチを適用しています。定期的なチェックで待機ループを実装する必要があり、中にスリープを入れたいです。

間に違いはありますか：

モンキーパッチ環境で？monkey-patch が time.sleep を処理するかどうか疑問に思っています