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

3
ピーターソンとデッカーのアルゴリズムの対比
ピーターソンとデッカーのアルゴリズムは非常によく似ており、多くの対称性を示しています。 私は次のような非公式言語でアルゴリズムを定式化しようとしました: Peterson's: "I want to enter." flag[0]=true; "You can enter next." turn=1; "If you want to enter and while(flag[1]==true&&turn==1){ it's your turn I'll wait." } Else: Enter CS! // CS "I don't want to enter any more." flag[0]=false; Dekker's: "I want to enter." flag[0]=true; "If you want to enter …

1
テストと設定またはスワップなしのハードウェアロックの実装はありますか?
ロックは、通常、テストと設定およびスワップマシンレベルの命令によって実装されます。これらを使用しない他の実装はありますか? また、クリティカルセクションの問題に対するすべてのハードウェアレベルのソリューションは、割り込みの無効化、テストと設定、およびスワップの3つだけに分類できると言えますか?

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

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

1
可変性のコンテキストで「単調性」とはどういう意味ですか
私はThe Rust Programming Languageを読んでいて、次の文章を見つけました: 構造体への書き込みはアトミック操作ではないことを忘れないでください。また、などの多くの関数vec.push()は内部的に再割り当てして安全でない動作を引き起こす可能性があるため、単調性でも正当化するのに十分ではない場合があります UnsafeCell それは本のどこからともなく出てきた、そして私はこの文脈でそれが正確に何を意味するのかを見つけることを試みるオンラインで苦労した。数学関数の「単調性」の概念に関する情報が多すぎます。これは、すでに知っていましたが、明らかにあまり役に立ちません。 それについて語っているこの記事だけを見つけたようです。 ここで、明白な方法で平等を尊重することに加えて、関数型プログラムは観測の単調性を尊重しなければならないという規定も含めます。これはどういう意味ですか?ある時点で何かを観察した後は、それが将来明らかになるのを止めることはないでしょう。これは、クリプケまたはベスのセマンティクスの単調性プロパティに類似しています。 しかし、これも非常に抽象的なものであり、同じことについて話されているかどうかはわかりません。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.