アカウント名:
パスワード:
が実装されるっぽいです。
変な話ですけど、priority inheritanceはちゃんと実装するんでしょうね? 現状の実装を見たら目が点になったので...
あと、C言語上で同じ文であってもarchitectureによってlockが必要だったりいらなかったりすることがありますよね(i386はsparcなどほかのarchitectureに比べてhardwa
実際のところ、Linux/UNIXレベルのOSに汎用の実時間処理機能を持たせるには、他にも多くの課題があります。
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は実装していない)、実は実行単位がspinではなくblockすることにより待機する、sleepable mutexがあります(Solarisのadaptive lockはその1種)。もちろん、必要ならばpriority inheritanceを行います。sleepable mutexが必要な理由は簡単で、全てのデータをspin lockで保護した場合、あるデータを多くのprocessorがlockしようとするとシステムに空きprocessorがなくなってしまうためです。したがって、kernelのうちschedulingに関わる部分などごく一部を除き、全てのデータはこのsleepable mutexで保護するのが普通です。Solarisの実装で理論的にpriority inheritanceがもっとも多く行われるのは、このsleepable mutexの場合です(実測しても間違いなくそうなるであろう)。
それから、このような話が出てくるとオウムがえしのようにrealtimeを考える人がいますが、それは決して本質ではありません。粒度の細かいlockが必要な最大の理由は、kernel内部の並列度を上げることにあります。これはTSS-likeに使うUnixでも十分役に立ちますし、従来の枠組みでは全く扱えなかったinterrupt handlingの並列化にはなくてはなりません。実際、Solarisを2 cpuの計算機(sun4u)で走らせていると、少しコンパイルするだけでもkernel timeが70-80%まで上がります。あるいは、まだGiant lockがとれていないFreeBSD-currentを4 cpuの計算機で走らせると、高々100程度のprocessでも30程度がGiant待ちを食らってしまいます。これらの現象を観察すると、mutexによるデータ保護はもちろん必要ですし、interrupt threadが不必要に遅延を食らわないようにするためにdispatch delayを減らす努力が必須であることも理解できます。realtimeはその技術を流用したために可能になる後付けであり、決して始めにrealtime有りきではありません。
おっしゃるとおり、応答性と並列性は別のものです。並列性を上げるための仕組みが、カーネル内プリエンプトを可能にする仕組みに流用できるという副次効果があるだけです。
ちなみに、sleep-wakeupによる同期が本質的にはcondition variableと等価ということも知っています。 ま、Linuxの場合、sleepable mutexの導入を考える以前に、ロックの粒度が大きいところを細かくするほうが先決です。今のままCPU数を増やすとファイルシステムの奥の方と、ブロックデバイス周りのロックの粒度が問題になるでしょう。 sleepable mutexを利用する場合も注意が必要だと思います。 sleepable mutexも万能ではなく、あらかじめ短いことがわかっている排他区間で利用するとコストが高くつきます。実際の実装では適当なところで妥協し、馬鹿spinlockと使い分けをするのが良いでしょう。（というかsleepable mutexが不必要なくらい全てのロック区間を短くするのが良い） sleepable mutexを採用するなら、まずLinuxの割り込み処理も、Solarisのようにスレッドとして動けるように書き直すことと、 ロックを握りっぱなしにされないようにプライオリティ継承かシーリングセマフォ的なものの導入することが必須となるでしょう。
ところで、一般にはプライオリティ継承は応答性を高める目的で実装されますが、「プライオリティ継承が必要だ！」と言われているのは、上記sleepable_mutexを前提とした話だったのでしょうか？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
新機能 (スコア:5, 参考になる)
2.5で入るかもしれない機能のなかではプロセスごとにファイルシステムの名前空間を分ける機能(CLONE_NAMESPACE?)と入出力のより一般的な扱い(マルチキーボード、マルチディスプレー、マウスによる複数端末としての利用)に期待しています。
あとは
が実装されるっぽいです。
Re:新機能 (スコア:5, 興味深い)
変な話ですけど、priority inheritanceはちゃんと実装するんでしょうね? 現状の実装を見たら目が点になったので...
あと、C言語上で同じ文であってもarchitectureによってlockが必要だったりいらなかったりすることがありますよね(i386はsparcなどほかのarchitectureに比べてhardwa
Re:新機能 (スコア:1)
スピンロックはCPU間の排他を行う仕組みです。スピンロック区間は普通割り込み禁止・プリエンプト禁止で瞬間的に走り抜けます。つまりこれ以上の優先度はありません
まあ、複数のCPUが同時にスピンロックを試みた時にどのCPUが、権利を取得できるかは運任せという問題はありますが。
確かにおっしゃるとおりsleep/wakeupメカニズムの方のプライオリティ継承は実装されていません。しかきこの機能を完全に実装しようと思うと非常にコストがかかります(資源確保のネスト、複数プロセスが資源を持っているときなど状態が非常に複雑です）。どこで妥協するかがポイントでしょう。Linuxでどのような実時間処理に利用したいか考えたうえで、最小限の実装するのが、まあ妥当なところでしょうか。
実際のところ、Linux/UNIXレベルのOSに汎用の実時間処理機能を持たせるには、他にも多くの課題があります。
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は実装していない)、実は実行単位がspinではなくblockすることにより待機する、sleepable mutexがあります(Solarisのadaptive lockはその1種)。もちろん、必要ならばpriority inheritanceを行います。sleepable mutexが必要な理由は簡単で、全てのデータをspin lockで保護した場合、あるデータを多くのprocessorがlockしようとするとシステムに空きprocessorがなくなってしまうためです。したがって、kernelのうちschedulingに関わる部分などごく一部を除き、全てのデータはこのsleepable mutexで保護するのが普通です。Solarisの実装で理論的にpriority inheritanceがもっとも多く行われるのは、このsleepable mutexの場合です(実測しても間違いなくそうなるであろう)。
それから、このような話が出てくるとオウムがえしのようにrealtimeを考える人がいますが、それは決して本質ではありません。粒度の細かいlockが必要な最大の理由は、kernel内部の並列度を上げることにあります。これはTSS-likeに使うUnixでも十分役に立ちますし、従来の枠組みでは全く扱えなかったinterrupt handlingの並列化にはなくてはなりません。実際、Solarisを2 cpuの計算機(sun4u)で走らせていると、少しコンパイルするだけでもkernel timeが70-80%まで上がります。あるいは、まだGiant lockがとれていないFreeBSD-currentを4 cpuの計算機で走らせると、高々100程度のprocessでも30程度がGiant待ちを食らってしまいます。これらの現象を観察すると、mutexによるデータ保護はもちろん必要ですし、interrupt threadが不必要に遅延を食らわないようにするためにdispatch delayを減らす努力が必須であることも理解できます。realtimeはその技術を流用したために可能になる後付けであり、決して始めにrealtime有りきではありません。
Re:新機能 (スコア:1)
おっしゃるとおり、応答性と並列性は別のものです。並列性を上げるための仕組みが、カーネル内プリエンプトを可能にする仕組みに流用できるという副次効果があるだけです。
ちなみに、sleep-wakeupによる同期が本質的にはcondition variableと等価ということも知っています。 ま、Linuxの場合、sleepable mutexの導入を考える以前に、ロックの粒度が大きいところを細かくするほうが先決です。今のままCPU数を増やすとファイルシステムの奥の方と、ブロックデバイス周りのロックの粒度が問題になるでしょう。
sleepable mutexを利用する場合も注意が必要だと思います。 sleepable mutexも万能ではなく、あらかじめ短いことがわかっている排他区間で利用するとコストが高くつきます。実際の実装では適当なところで妥協し、馬鹿spinlockと使い分けをするのが良いでしょう。（というかsleepable mutexが不必要なくらい全てのロック区間を短くするのが良い） sleepable mutexを採用するなら、まずLinuxの割り込み処理も、Solarisのようにスレッドとして動けるように書き直すことと、 ロックを握りっぱなしにされないようにプライオリティ継承かシーリングセマフォ的なものの導入することが必須となるでしょう。
ところで、一般にはプライオリティ継承は応答性を高める目的で実装されますが、「プライオリティ継承が必要だ！」と言われているのは、上記sleepable_mutexを前提とした話だったのでしょうか？