アカウント名:
パスワード:
が実装されるっぽいです。
変な話ですけど、priority inheritanceはちゃんと実装するんでしょうね? 現状の実装を見たら目が点になったので...
あと、C言語上で同じ文であってもarchitectureによってlockが必要だったりいらなかったりすることがありますよね(i386はsparcなどほかのarchitectureに比べてhardwa
sleep-wakeupによる同期というのは、本質的にはlock primitiveの1種であるcondition variableと等価です(他はmutexとshared-exclusive lock)。したがって、同期をとるべき資源の持ち主は一般的にはわからず、priority inheritanceは確かに困難です。condition variableについてはSolarisもpriority inheritaceは行ってしません。shared-exclusive lockではowner-of-recordに対してpriority inheritanceを行うことにより、疑似的に実現しています。
この感じだと世の中にはあまり知られていないようですが(少なくともLinux kernelは実装していな
おっしゃるとおり、応答性と並列性は別のものです。並列性を上げるための仕組みが、カーネル内プリエンプトを可能にする仕組みに流用できるという副次効果があるだけです。
ちなみに、sleep-wakeupによる同期が本質的にはcondition variableと等価ということも知っています。 ま、Linuxの場合、sleepable mutexの導入を考える以前に、ロックの粒度が大きいところを細かくするほうが先決です。今のままCPU数を増やすとファイルシステムの奥の方と、ブロックデバイス周りのロックの粒度が問題になるでしょう。 sleepable mutexを利用する場合も注意が必要だと思います。 sleepable mutexも万能ではなく、あらかじめ短いことがわかっている排他区間で利用するとコストが高くつきます。実際の実装では適当なところで妥協し、馬鹿spinlockと使い分けをするのが良いでしょう。（というかsleepable mutexが不必要なくらい全てのロック区間を短くするのが良い） sleepable mutexを採用するなら、まずLinuxの割り込み処理も、Solarisのようにスレッドとして動けるように書き直すことと、 ロックを握りっぱなしにされないようにプライオリティ継承かシーリングセマフォ的なものの導入することが必須となるでしょう。
ところで、一般にはプライオリティ継承は応答性を高める目的で実装されますが、「プライオリティ継承が必要だ！」と言われているのは、上記sleepable_mutexを前提とした話だったのでしょうか？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
新機能 (スコア:5, 参考になる)
2.5で入るかもしれない機能のなかではプロセスごとにファイルシステムの名前空間を分ける機能(CLONE_NAMESPACE?)と入出力のより一般的な扱い(マルチキーボード、マルチディスプレー、マウスによる複数端末としての利用)に期待しています。
あとは
が実装されるっぽいです。
Re:新機能 (スコア:5, 興味深い)
変な話ですけど、priority inheritanceはちゃんと実装するんでしょうね? 現状の実装を見たら目が点になったので...
あと、C言語上で同じ文であってもarchitectureによってlockが必要だったりいらなかったりすることがありますよね(i386はsparcなどほかのarchitectureに比べてhardwa
Re:新機能 (スコア:1)
スピンロックはCPU間の排他を行う仕組みです。スピンロック区間は普通割り込み禁止・プリエンプト禁止で瞬間的に走り抜けます。つまりこれ以上の優先度はありません
まあ、複数のCPUが同時にスピンロックを試みた時にどのCPUが、権利を取得できるかは運任せという問題はありますが。
確かにおっしゃるとおりsleep/wakeupメカニズムの方のプライオリティ継承は
Re:新機能 (スコア:2)
sleep-wakeupによる同期というのは、本質的にはlock primitiveの1種であるcondition variableと等価です(他はmutexとshared-exclusive lock)。したがって、同期をとるべき資源の持ち主は一般的にはわからず、priority inheritanceは確かに困難です。condition variableについてはSolarisもpriority inheritaceは行ってしません。shared-exclusive lockではowner-of-recordに対してpriority inheritanceを行うことにより、疑似的に実現しています。
この感じだと世の中にはあまり知られていないようですが(少なくともLinux kernelは実装していな
Re:新機能 (スコア:1)
おっしゃるとおり、応答性と並列性は別のものです。並列性を上げるための仕組みが、カーネル内プリエンプトを可能にする仕組みに流用できるという副次効果があるだけです。
ちなみに、sleep-wakeupによる同期が本質的にはcondition variableと等価ということも知っています。 ま、Linuxの場合、sleepable mutexの導入を考える以前に、ロックの粒度が大きいところを細かくするほうが先決です。今のままCPU数を増やすとファイルシステムの奥の方と、ブロックデバイス周りのロックの粒度が問題になるでしょう。
sleepable mutexを利用する場合も注意が必要だと思います。 sleepable mutexも万能ではなく、あらかじめ短いことがわかっている排他区間で利用するとコストが高くつきます。実際の実装では適当なところで妥協し、馬鹿spinlockと使い分けをするのが良いでしょう。（というかsleepable mutexが不必要なくらい全てのロック区間を短くするのが良い） sleepable mutexを採用するなら、まずLinuxの割り込み処理も、Solarisのようにスレッドとして動けるように書き直すことと、 ロックを握りっぱなしにされないようにプライオリティ継承かシーリングセマフォ的なものの導入することが必須となるでしょう。
ところで、一般にはプライオリティ継承は応答性を高める目的で実装されますが、「プライオリティ継承が必要だ！」と言われているのは、上記sleepable_mutexを前提とした話だったのでしょうか？