アカウント名:
パスワード:
Preemptionについては本当にsourceや他のOSの実装を見たのか疑わしいところがあります。現状のLinux kernelではlock primitiveが貧弱です(特に、adaptive/blocking lockで十分なところにspin lockを使っている)。これはkernelのあちこちでinterrupt levelを引き上げることになります。結果として、割込そのものが遅れるために測定不可能なdispatch delayが生じる恐れがあります。
FreeBSDの場合、最も基本となるlockはblocking lock(多くは将来adaptiveに変更予定)です。spin lockはscheduler lockなど4種類しか用いていません。また、割込も、
FreeBSDの場合、i386ではsysctlによりpreemption不可能であっても許可することが可能です。この場合、割込threadが実行可能でなければ通常通りrun queueにぶち込まれます。違いは、その後にmi_switch()を呼び出さない(通常は呼び出すので割込threadが直ちに実行される)というだけです。
s/不可能であっても許可する/不可能であっても割込を許可する/
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
見えないdispatch delayが残りそう (スコア:3, 参考になる)
Preemptionについては本当にsourceや他のOSの実装を見たのか疑わしいところがあります。現状のLinux kernelではlock primitiveが貧弱です(特に、adaptive/blocking lockで十分なところにspin lockを使っている)。これはkernelのあちこちでinterrupt levelを引き上げることになります。結果として、割込そのものが遅れるために測定不可能なdispatch delayが生じる恐れがあります。
FreeBSDの場合、最も基本となるlockはblocking lock(多くは将来adaptiveに変更予定)です。spin lockはscheduler lockなど4種類しか用いていません。また、割込も、
補足 (スコア:1)
FreeBSDの場合、i386ではsysctlによりpreemption不可能であっても許可することが可能です。この場合、割込threadが実行可能でなければ通常通りrun queueにぶち込まれます。違いは、その後にmi_switch()を呼び出さない(通常は呼び出すので割込threadが直ちに実行される)というだけです。
補足の補足 (スコア:1)
s/不可能であっても許可する/不可能であっても割込を許可する/