タグ付けされた質問 「threads」

4
一般的にどのスレッドが共有しますか?
さて、これは一般的な質問です。そして、もし誰かがそれを実装固有にしたいなら、私はUnix関連のものを好むでしょう。しかし、まず一般的に次の問題を知る必要があります。 私は単一のプロセスが複数のスレッドを持つことができると読みました。同じプロセスの複数のスレッドは、それらの間で物事を共有します。彼らが何を共有し、何を共有していないのか知りたい。プロセスがアドレス空間、スタック、ヒープ、グローバル変数、コード、データ、OSリソースで構成されていることを考慮して、スレッド間で共有されるものは何ですか?私は次の推測を持っています: グローバル変数-スレッド共有グローバル変数を読み取りました。また、JavaとC#でプログラミングしているときに、クラスレベルの変数を共有するスレッドを作成しました。したがって、スレッドはグローバル変数を共有すると信じています(ただし、高レベルのプログラミング言語の概念がそのまま低オペレーティングシステムレベルの事実に変換されるかどうかはわかりません)。 ヒープ-グローバル変数はヒープに格納されるため、ヒープはスレッド間で共有されます。 スタック-各スレッドは独自の実行シーケンス/コードを持つことができるため、プログラムカウンターの内容をプッシュ/ポップする独自のスタックを持っている必要があります(関数呼び出しと戻りが発生した場合)。したがって、同じプロセスのスレッドはスタックを共有しません。 今、私は次のものの共有について確信が持てない アドレス空間-アドレス空間で何が正確にカウントされるのかわからない。しかし、アドレス空間は一般的にスレッドではなくプロセスのコンテキストで使用されると思います。また、同じプロセスのすべてのスレッドは親プロセスと同じアドレス空間に存在するため、スレッドはアドレス空間を共有すると言われています。(しかし、それらは同じアドレス空間内で異なるスタックを維持しますか?) OSリソース-これは非常に実装固有であると思います。たとえば、親プロセスは、すべてではなくそのスレッドの一部に同じファイルのハンドルを選択的に与えることができます。または私は誤解しており、OSリソースはファイル以外のものを意味しますか? コード-スレッドは異なるコードを持つことができるため、コードの共有が常に当てはまるわけではありません。 データ-データの下で何を考慮すべきかわからない。ただし、グローバル変数がスレッド間で共有されていることを確認してください。そして、ローカル変数が同様に共有されていないことを確認してください。 全体的に、あいまいな用語、オペレーティングシステムの書籍で行われている超一般化、およびオンラインで提供される実装固有の詳細により、かなり混乱しています。だから私は私を満足させることができるいくつかの答えを見つけようとしています。

3
なぜほとんどのミューテックス実装は不公平なのですか?
私の理解では、mutexの最も一般的な実装(たとえば、C ++のstd :: mutex)は公平性を保証していません-つまり、競合のインスタンスで、ロックがスレッドの順序で取得されることを保証していません lock()と呼ばれます。実際には、(できれば一般的ではありませんが)競合が多い場合に、mutexの取得を待機しているスレッドの一部がmutexを取得できない可能性さえあります。 これは私には役に立たない振る舞いのようです-公平なミューテックスは、プログラマーが望んでいる/期待することにより一致した振る舞いをもたらすように思えます。 mutexが通常公平に実装されない理由は「パフォーマンス」ですが、それが何を意味するのかを理解したいと思います。特に、mutexの公平性要件を緩和すると、パフォーマンスがどのように向上しますか?「フェアな」ミューテックスを実装するのは簡単なようです-スレッドをスリープ状態にする前に、lock()がミューテックスのリンクリストの末尾に呼び出しスレッドを追加し、次にロック解除()で次のスレッドをポップしてくださいその同じリストの頭とそれを目覚めさせます。 ここで見逃しているミューテックス実装の洞察は、より良いパフォーマンスのために公平性を犠牲にすることが価値があると考えられた理由を説明していますか?

1
ハイパースレッディングを使用するとパフォーマンスが低下する理由
ハイパースレッディングがパフォーマンスの低下につながることを、このようなさまざまな場所で読んだことがあります。 ハイパースレッディングがパフォーマンスの低下を引き起こす理由と方法を理解できません。 なぜハイパースレッディングによってOSが空きリソースを利用できるようになっても、パフォーマンスが低下するのはなぜですか。 ベンチマークはハイパースレッディングを原因として示していますが、誰かがこの理由を説明できます。 ありがとう

3
スレッドの安全性を証明することは可能ですか?
変数とこれらの変数を変更する命令で構成されるプログラム、および同期プリミティブ(モニター、ミューテックス、Javaの同期またはC#のロック)が与えられた場合、そのようなプログラムがスレッドセーフであることを証明できますか? スレッドセーフティやレース条件などを記述するための正式なモデルさえありますか?

2
ファイバーが複数のプロセッサを利用できないのはなぜですか?
ファイバーとスレッドの違いは、ファイバーが協調的にスケジュールされるのに対し、スレッドは先制的にスケジュールされることです。スケジューラのポイントは、CPUを「タイムシェアリング」することによって、それ以外の場合はシリアルプロセッサリソースを並列に動作させる方法のように見えます。ただし、各コアが独自のスレッドを実行しているデュアルコアプロセッサでは、シングルプロセッサが「タイムシェアリング」されていないため、一方のスレッドの実行を一時停止してもう一方のスレッドを続行する必要がないと思います。 それで、スレッドとファイバーの違いがスケジューラーによって中断される方法であり、物理的に別々のコアで実行しているときに中断する必要がない場合、スレッドが可能なときにファイバーが複数のプロセッサーコアを利用できないのはなぜですか? 混乱の原因: ..主にウィキペディア http://en.wikipedia.org/wiki/Fiber_%28computer_science%29 欠点は、ファイバーがプリエンプティブスレッドを使用せずにマルチプロセッサマシンを利用できないことです。 http://en.wikipedia.org/wiki/Computer_multitasking#Multithreading ... [ファイバー]は、複数のプロセッサを搭載したマシンのスレッドの利点の一部またはすべてを失う傾向があります。

1
静止整合性が構成的であるが、順次整合性が構成されていない理由
これら2つのメモリ整合性モデルの比較に問題があります。 基本的には、シーケンシャルな一貫性のために、次のような実際のコードを考えます。 int x, y; void ThreadA() { x = 20; //Write int a = y; //Read } void ThreadB() { y = 20; int b = x; } シーケンシャル一貫性の環境ではそれは不可能だためaか、bのどちらかである20ではないとa = 20、b = 20かa = 20 && b = 20。 しかし、静止時の一貫性はこの例にどのように適合し、なぜ構成的であるのでしょうか。

1
ロックの一貫性のない状態
私はマルチプロセッサプログラミングのアートを読んでおり、一貫性のないロックの概念を理解しようとしています。具体的には、37ページで、一貫性のないロックの定義2.8.1と補題2.8.1は私には明確ではありません。 定義2.8.1。Lockオブジェクトの状態sは、一部のスレッドがクリティカルセクションにあるグローバル状態では一貫していませんが、ロック状態は、クリティカルセクションにスレッドがない、またはスレッドが開始しようとしているグローバル状態と互換性があります。 補題2.8.1デッドロックのないロックの実装が不整合な状態になることはありません。 証明: Lockオブジェクトが一貫性のない状態sであり、クリティカルセクションにスレッドが存在しないか、スレッドが開始しようとしているとします。スレッドBがクリティカルセクションに入ろうとすると、実装にデッドロックがないため、スレッドBは最終的に成功する必要があります。 Lockオブジェクトが不整合な状態sにあるとします。ここで、Aはクリティカルセクションにあります。スレッドBがクリティカルセクションに入ろうとする場合、スレッドBはAが出るまでブロックする必要があります。BはAがクリティカルセクションにあるかどうかを判断できないため、矛盾があります。 わからないこと: 一貫性がないということは、スレッドがクリティカルセクションにある場合、他のスレッドがそれについて知ることができないということだけを意味しますか? 補題証明の矛盾は何ですか?スレッドAがクリティカルセクションにあり、ロックが不整合な状態にあるとします。別のスレッドがロックの状態を上書きして取得するのを阻止するものは何ですか?

1
スレッドとロックに関する質問
私は現在、Fuss、Futexes、Furwocks:LinuxのFast Userland Lockingを読んでいて、この引用に出くわしました: 公平なロック方式では、ロックは要求された順序で許可されます。これは、コンテキストスイッチの数が増えるため、スループットに悪影響を与える可能性があります。同時に、それはいわゆるコンボイ問題を引き起こす可能性があります。ロックは到着順に付与されるため、すべてが最も遅いプロセスの速度で進行し、待機中のすべてのプロセスの速度が低下します。コンボイの問題に対する一般的な解決策は、解放時にロックを使用可能としてマークし、すべての待機中のプロセスをウェイクさせて、ロックを再競合させることです。これはランダムフェアネスと呼ばれます。しかし、これは雷鳴の群れの問題にもつながります。これにもかかわらず、ウェイクする最初のタスクがプリエンプトまたはスケジュールされる前にロックを解放し、2番目の群れのメンバーがロックを取得できるようにすれば、ユニプロセッサーシステムでうまく機能します。 この引用についていくつか質問があります。 第1に、さまざまなタスクが異なるタイミングでプロセスを待機キューに入れるため、公平なロックスキームはコンテキストスイッチの数を増やしますか。 次に、到着順にロックを許可すると、プロセスは最も遅いプロセスの速度でどのように進行しますか?これは、最も遅いプロセスが他のプロセスの前にロックを許可されている場合にのみ該当しませんか?同様に、ロックに対してランダムに競合するプロセスがあると、どのようにしてコンボイ問題が解決されますか? 最後に、マルチプロセッサシステムと比較して、ユニプロセッサシステムではランダムな公平性がどのように優れているか理解できません。たとえば、どちらの場合でも、待機中のプロセッサはすべて起こされ、1つはロックを取得し、他のプロセッサは再びスリープ状態にする必要があります。では、これはどのようにユニプロセッサシステムでうまく機能するのでしょうか。

1
スレッドはどのように異なるOSに実装されていますか?
私はこれに出くわしたRobert LoveによるLinuxカーネル開発を読んでいました Linuxは、スレッドのサポートに興味深いアプローチを採用しています。これは、スレッドと通常のプロセスを区別しません。カーネルにとって、すべてのプロセスは同じです。たまたま、リソースを共有するプロセスもあります。 OS(詳細はアスパイア)とカーネルについてはあまり知りません。そのため、上記の引用は、さまざまなOS(少なくともWindows、Linux、Unixなどの一般的なOS)でのスレッド実装について疑問を投げかけました。 誰かがOSでスレッドサポートを提供するためのさまざまな手法を説明できますか?(そしてオプションでそれらを対比する)
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.