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

私は現在、私の大学の同時プログラミングコースに参加しており、最近モニターの概念について話し始めました。相互排除の必要性については理解していますが、なぜモニターを使うのか分かりません。 私が理解しているように、モニターは常に1つまたはまったくプロセスがクリティカルセクションにないことを保証します。セマフォでそれを実現できます。さらに、セマフォを使用してモニターを実装します（またはモニターを実装するための少なくとも1つの可能性があります）。 では、なぜセマフォを備えたセマフォとまったく同じことを実装するのでしょうか？どのようなメリットがありますか？

11 concurrency  synchronization  mutual-exclusion 

ドリンクディスペンサーは、（コインを挿入するために、ユーザが必要です：）三つのボタンの、そしてプレス1 ˉ Dのお茶は、お茶のカップを要求Eの紅茶、コーヒーのため同上を、そしてˉ rは払い戻しを要求する（つまり、マシンが戻っていますコイン：ˉ B）。このディスペンサーは、次のCCSプロセスによってモデル化できます。c¯c¯\bar cd¯お茶d¯tea\bar d_{\text{tea}}eお茶eteae_{\text{tea}}r¯r¯\bar rb¯b¯\bar b M=d e fc 。（dお茶。e¯お茶。M+ dコーヒー。e¯コーヒー。M+ r 。b¯。M）M=defc.(dtea.e¯tea.M+dcoffee.e¯coffee.M+r.b¯.M) M \stackrel{\mathrm{def}}= c.(d_{\text{tea}}.\bar e_{\text{tea}}.M + d_{\text{coffee}}.\bar e_{\text{coffee}}.M + r.\bar b.M) 内戦はコーヒーの価格を2コインに引き上げますが、お茶の価格は1コインのままです。私たちは、2枚のコインの後にのみコーヒーを配達し、1枚または2枚のコインの後に払い戻しを受け入れるように変更されたマシンを求めています。変更したマシンをCCSプロセスでどのようにモデル化できますか？

11 logic  concurrency  modelling  process-algebras  ccs 

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

11 concurrency  synchronization  threads 

私の背景は、主にC、C ++、およびPythonの命令型言語から来ました。私は数年後、Scala、Erlang、およびHaskellの一部を入手し、関数型プログラミングとその背後にある形式に非常に興味を持つようになりました。 私は並行プログラミングと分散プログラミングにも興味があり、その背後にある形式、特に「日中の光」のほんの少しだけを見たもの（例：実世界での使用、または少なくともどこかでの実装）を調べています。これまでのところ、通信順次プロセス、アクターモデル、通信プロセスの代数、および通信システムの計算について知っています。これらの中で、アクターモデルがErlang、Scala、Haskellなどの言語で実現したことを知っています。 これらの分野に取り組む前に、学んだり実践したりすべき基礎があるのか​​、最初に学ぶべき「古典的」な基礎があるのか​​、他に見逃したかもしれない人気のある基礎があるのだろうか。

10 distributed-systems  concurrency 

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

9 proof-techniques  correctness-proof  concurrency  threads 

私は中にいると思いピーターソンのアルゴリズムのための相互排除プロセスが最初のクリティカルセクションを入力する場合は、クリティカルセクションに入るのを待って、永遠に死ぬこと、またはキャンセルされ、他のプロセスだろうループました。 この図では、プロセス1が停止した場合、プロセス1の背後にある残りのプロセスは、プロセス1の場所まで実行されますが、その後ループします。 クリティカルセクションに到達したプロセスが、終了する前に最初に停止した場合はどうなりますか？

9 programming-languages  concurrency  mutual-exclusion 

相互排除アルゴリズムについてはかなりの量の研究が行われています。たとえば、その多くは、マルチプロセッサプログラミングのような古典的な教科書で紹介されており、章全体がそれらに向けられています。 一般的な言語とOSが提供する同期プリミティブ（たとえば、pthreadライブラリによって提供される）を使用するのではなく、コンカレントシステムのエンジニアリング中にこれらのアルゴリズムが必要になる可能性がある実際の状況は何でしょうか。 標準のプリミティブが特別に調整されていないと思われる多くの特殊なケースを考えることができます。 -そのような状況での実践において、教科書の相互排除アルゴリズムのいずれかが大幅に改善されていますか？ 簡単に言えば、どの相互排除アルゴリズムが、並行処理プリミティブの典型的な言語提供ライブラリをすでに自由に使えるエンジニアに実際に関連していますか？

8 reference-request  concurrency  mutual-exclusion 

これら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。 しかし、静止時の一貫性はこの例にどのように適合し、なぜ構成的であるのでしょうか。

7 concurrency  cpu-cache  threads  shared-memory 

ソフトウェアのトランザクションメモリのコンテキストで、直列化可能性と線形化可能性を把握しようとしています。ただし、どちらの概念も一般的にトランザクションメモリに適用できると思います。 この時点で、私は両方の主題について次のように理解しています。 シリアライザビリティ 直列化可能性はグローバルプロパティです。これはトランザクションの正確性のプロパティです。与えられたk各トランザクションを実行することのプロセスTkを同時に（すなわち、次々に）順番に実行することができるトランザクションの順序があることを直列化可能性を保証最終結果は同じであるようにトランザクションが同時に実行されるように。したがって、(T1, T2,..,Tk)順次実行できるトランザクションのリストを定義するリストの順列があります。 この特性は私には完全に理にかなっており、私の定義は正しいと思います。この定義は、HerlihyとShavitによる「The Art of Multiprocessor programming」のテキストに基づいています。 線形化可能性 線形化可能性は、並行オブジェクトのローカルプロパティです（たとえば、スレッド間で共有されるクラスのインスタンス）。線形化可能性により、2つのプロセスがそれぞれ、その共有オブジェクトで一連のopメソッド呼び出し（例、queueまたはインスタンス）を実行するときdequeueに、プログラムの順序（プログラマーQueueが記述した順序）を必ずしも保持しない、これらのメソッド呼び出しの順次的な順序付けが保証されます。ダウン）、ただし、各メソッド呼び出しは即座に行われるように見えます（つまり、呼び出しと応答が直接互いに続きます）。一方、各メソッド呼び出しの結果は個別に維持され、結果としてオブジェクトの状態も維持されます。 質問 "On the correctness of TM"GuerraouiとKapalkaによる論文によると、これはTMの文脈における線形化可能性の定義です。 ..共有オブジェクトを説明するために考案された安全プロパティは、TMの修正基準として使用されることがあります。TMの用語では、線形化可能性とは、直感的には、すべてのトランザクションがその存続期間中のある特定の時点で行われたかのように見える必要があることを意味します。 この定義は、私にとって直列化可能性に似ているようです。しかし、この論文では、シリアライザビリティを次のように定義しています。 ..は、データベーストランザクションの最も一般的に必要なプロパティの1つです。大まかに言えば、トランザクションの履歴H（つまり、特定の実行ですべてのトランザクションによって実行されるすべての操作のシーケンス）は、Hでコミットされたすべてのトランザクションが同じ操作を発行し、 Hでコミットされたトランザクションのみの（連続した履歴は、トランザクション間の同時実行性のない履歴です）。 ただし、この定義は、トランザクションからステートメントを並べ替えて、インターリーブできることを意味しているようです。（つまり、トランザクションのすべてのステートメントTがに順番に表示されるわけではないようにステートメントを並べ替えますH）。 私は、上記の個人的な定義が正しいと想定しています。私の実際の質問は、線形化可能性がトランザクションメモリのコンテキストでどのように定義されるかです。トランザクションメモリのセマンティクスが壊れるので、トランザクション内の各メソッド呼び出し（つまり、読み取り/書き込み操作）を個別に説明しても意味がありません。これは明らかに直列化可能性を損なうので、2つの同時トランザクションとそれらのインターリーブについて推論する必要があるのも意味がありません。線形化可能性とは、トランザクション内の個々の操作を並べ替えることができるということですか？線形化可能性が直列化可能性のより強力な形式である場合、操作が単一のトランザクション内で実行される順序は重要ではありません。 要約すると、まず第一に、直列化可能性と線形化可能性に対する私の理解は正しいですか？さまざまな作品で大量の定義を読んだ後、私は混乱しています。次に、一連のトランザクションを線形化できるとはどういう意味ですか？ コメントの中にリンクされた質問も読んだ。しかし、それは私の特定の質問を私に説明しませんでした。 出典 トピックに関するSOの質問（STMについては明確ではありません） /programming/4179587/difference-between-linearizability-and-serializability 2つのhttp://www.bailis.org/blog/linearizability-versus-serializability/に関する非公式の説明 シリアライザビリティに関する元の論文 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.2690&rep=rep1&type=pdf [1]線形化可能性に関する最初の論文 http://www.cs.toronto.edu/~christoff/files/Linearizability-ACorrectnessConditionForConcurrentObjects.pdf

7 distributed-systems  concurrency  databases 

「ヘテロジニアスレースフリーメモリモデル」[1]の論文では、SC-DRFではアトミックのみで構成されるプログラムはレースフリーであるが、HRFダイレクトではないという記述があります。これがなぜなのか理解できません。これがどのように起こるかを誰かが説明できますか？ [1] Derek R. Hower et al。、「異質レースフリーメモリモデル」。でASPLOS '14の議事録、ACM、2014年（PDF）

7 concurrency 

私はマルチプロセッサプログラミングのアートを読んでおり、一貫性のないロックの概念を理解しようとしています。具体的には、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がクリティカルセクションにあり、ロックが不整合な状態にあるとします。別のスレッドがロックの状態を上書きして取得するのを阻止するものは何ですか？

7 terminology  concurrency  threads  deadlocks 

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

7 concurrency  threads 

チューリングマシンがオートマトンと同等の場合 λλ\lambda 微積分、オートマトンに相当するものは何ですか ππ\pi微積分？それは、チューリングマシンに似たある種のオートマトンであると思いますが、通信チャネルまたは特定のタイプの信号をサポートしていますが、確信が持てず、方向性を高く評価します。

7 automata  concurrency  machine-models  pi-calculus