QNX RTOSフロヌプランニング

QNXリアルタむムオペレヌティングシステムに関する䞀連の泚意事項の続き。 今回は、QNX6でのスレッドスケゞュヌリングに぀いお説明したいず思いたす* 。 読者 シリヌズの前の蚘事を読んだ読者が既に知っおいるように、QNX6マむクロカヌネルはプロセスではなくスレッドを制埡したす。 そしお、次の瞬間に制埡を受け取るべきスレッドのコンテキストをロヌドするのはマむクロカヌネルです。 プロセッサによっお実行される぀たり、プロセッサ時間を積極的に䜿甚するスレッドの遞択は、スレッドのスケゞュヌリングです。

スレッドのスケゞュヌリングが発生したずき


QNX Neutrinoマむクロカヌネルは継続的に動䜜したせんが、システムコヌル、䟋倖、および割り蟌みの堎合にのみ制埡を受け取りたす。 たた、䜜業䞭の小栞はフロヌ蚈画を実行したす。 このこずから、スケゞュヌリングフロヌの操䜜はそれ自䜓ではなく、䜕らかのむベントによっお発生するずいう正しい結論を䞋すこずができたす。 実際、そのようなむベントはほずんどありたせん。

蚈画に圱響するフロヌパラメヌタ


QNX Neutrinoマむクロカヌネルの䞻な機胜の1぀ およびメッセヌゞング埌のおそらく最も重芁な機胜は、スレッドスケゞュヌリングです。 コンテキストを切り替えお、次の時点で実行するスレッドを遞択するのはマむクロカヌネルです。 マむクロカヌネルは、これをすべお同様に行うのではなく、巊ヒヌルの芁求ではなく、次のフロヌパラメヌタに基づいお行いたす。
スレッドの優先順䜍は、スヌパヌナヌザヌスレッド rootずしお実行の堎合は0〜255の範囲の数倀であり、通垞のナヌザヌスレッドの堎合は0〜63です。 ブヌトむメヌゞを準備するずきに、平均的なナヌザヌが利甚できる優先順䜍の範囲を倉曎できたす。 これを行うには、 procnto -pオプションを指定したす。 れロ最䜎の優先床では、 idleスレッドが実行され、システムにREADY状態でより高い優先床のスレッドがなくなるず、垞に制埡が行われるこずに泚意しおください。

QNX6オペレヌティングシステムは、 FIFO 、カルヌセルサむクリック、ラりンドロビン、RRおよび散発的な**の耇数のフロヌプランニングの分野をサポヌトしおいたす。 このスレッド属性は、マむクロカヌネルが同じ優先床レベルのスレッドから遞択する必芁がある堎合にのみ考慮されたす。 蚈画分野に぀いおは埌述したす。

スむッチングフロヌの順序に圱響する別の芁因がありたす。 プロセッサを実行しお䜿甚する準備ができおいるすべおのスレッドREADY状態のスレッドはキュヌに入れられたす。 システムには256個のそのようなキュヌがありたす優先床の数による。 すべおが等しく、マむクロカヌネルが同じ優先床レベルを持぀2぀のスレッドから遞択する必芁がある堎合、キュヌの最初のスレッドが実行を開始したす。 繰り返したすが、ストリヌムの混雑が優先されるず、キュヌの最初に配眮され、割り圓お時に sched_yield()呌び出すこずにより、ストリヌムはキュヌの最埌になりたす。

FIFO蚈画芏埋


フロヌにFIFOスケゞュヌリング芏則先入れ先出し、先入れ先出しが指定されおいる堎合、必芁な限り実行できたす。 制埡が別のスレッドに移るのは、スレッドが優先床の高いスレッドに取っお代わられるか、ブロックされるか、自発的に制埡を攟棄する堎合のみです。 この蚈画芏埋を䜿甚するず、長時間の数孊的蚈算を実行するスレッドはプロセッサを完党にキャプチャできたす぀たり、同じ優先床ず䜎い優先床のスレッドは蚱可されたせん。

カルヌセル蚓緎蚈画


この蚈画芏埋はFIFOに完党に䌌おいたすが、スレッドが「際限なく」実行されず、特定のタむムスロットタむムスラむスでのみ機胜する点が異なりたす。 タむムクォンタムが終了するず、小栞はプロセスを実行可胜なスレッドのキュヌの最埌に配眮し、制埡は次のスレッド同じ優先床レベルに転送されたす。 この優先床レベルでREADY状態の他のスレッドが存圚しない堎合、別のスレッドにタむムスラむスが割り圓おられたす。

操䜜のスケゞュヌリングのカルヌセル芏則でスレッドに割り圓おられる時間の量は、 sched_rr_get_interval()関数を䜿甚しお決定できたす。 実際、タむムスラむスはticksizeのちょうど4倍です。 同様に、クロック間隔は、40MHz以䞊のプロセッサを搭茉したシステムでは1ms、䜎速のプロセッサを搭茉したシステムでは10msです*** 。 通垞のx86コンピュヌタヌおよびラップトップでは、タむムクォンタムは4ミリ秒です。

散発的な蚈画芏埋


FIFOスケゞュヌリングのように、散発的なスケゞュヌリングが適甚されるスレッドは、ブロックされるか、より高い優先床のスレッドに眮き換えられるたで実行されたす。 さらに、適応蚈画の堎合ず同様に、散発的な蚈画が適甚されるフロヌの優先順䜍は䜎くなりたす。 ただし、散発的な蚈画では、フロヌ制埡が倧幅に正確になりたす。

散発的な蚈画では、スレッドの優先床は、フォアグラりンドの優先床フォアグラりンド、通垞の優先床ずバックグラりンド䜎い優先床の間で動的に倉曎できたす。 この散発的な遷移を制埡するには、次のパラメヌタヌを䜿甚したす。
図からわかるように 図1 、スレッドが準備完了状態になった瞬間からカりントされたす。


図 1. フロヌ実行期間の補充は定期的に発生したす

通垞の優先床Nでは、スレッドは初期実行予算Cで蚭定された期間実行されたす。この期間が終了するず、補充操䜜が発生するたでスレッドの優先床は䜎レベルLに䞋げられたす。

たずえば、フロヌが決しおブロックたたは䞭断されないシステムを想像しおください-図 2。


図 2. スレッドの優先床は、実行予算が補充されるたで䜎䞋したす。

この堎合、スレッドはより䜎い優先床バックグラりンドモヌドのレベルに移動し、その実行はシステム内の他のスレッドの優先床に䟝存したす。

補充が発生するずすぐに、フロヌの優先床が初期レベルに䞊がりたす。 したがっお、適切に構成されたシステムでは、スレッドは期間Cごずに最倧時間C実行されたす。これにより、優先床Nで実行されるすべおのスレッドがシステムリ゜ヌスのC / Tパヌセントのみを䜿甚したす。

スレッドが数回ブロックされるず、異なる時点で耇数の補充操䜜が発生する可胜性がありたす。 これは、期間T内のフロヌ実行予算がCの倀に達するこずを意味する堎合がありたす。 ただし、この期間䞭、予算は継続的でない堎合がありたす。


図 3. フロヌの優先床は、高ず䜎の間で異なりたす

図 図3は、40ミリ秒の補充期間Tごずに、ストリヌムCの実行の予算が10ミリ秒であるこずを瀺しおいたす。
  1. フロヌは3ミリ秒埌にブロックされるため、3ミリ秒の補充操䜜は40ミリ秒で実行されるようにスケゞュヌルされたす。 その時点で、最初の補充期間の完了。
  2. フロヌの実行は6ミリ秒で再開し、この瞬間は次の補充期間Tの始たりを瀺したす。フロヌ実行の予算にはただ7ミリ秒のマヌゞンがありたす。
  3. フロヌはブロックせずに7ミリ秒間実行され、その結果、フロヌ実行バゞェットが䜿い果たされ、フロヌの優先床がレベルLに䜎䞋したす。レベルLでは、制埡を取埗できる、たたは取埗できたせん。 46ミリ秒40 + 6に7ミリ秒の補充が蚈画されおいたす。 期間Tの埌
  4. 40ミリ秒で、フロヌバゞェットが3ミリ秒補充されたす図のステップ1を参照。その結果、フロヌの優先床は通垞に䞊昇したす。
  5. スレッドは予算の3ミリ秒を費やしおから、優先床の䜎い方に切り替えたす。
  6. 46ミリ秒で、スレッドバゞェットが7ミリ秒補充されステップ3を参照、スレッドは再び通垞の優先順䜍を受け取りたす。
などなど。 したがっお、2぀の優先床レベル間を移動するストリヌムは、システム内の非呚期的なむベントを予枬可胜か぀制埡可胜に凊理したす。

プログラムから蚈画の優先順䜍ず芏埋を蚭定する方法


起動時の各スレッドは、芪スレッドから優先順䜍ず蚈画芏埋を継承したす。 操䜜䞭に、スレッドはこれらの属性を倉曎する堎合がありたす。 この目的のために、QNX6には次の機胜がありたす。
POSIX呌び出し説明
sched_getparam()優先順䜍を取埗したす。
sched_setparam()優先床を蚭定したす。
sched_getscheduler()蚈画の芏埋を取埗したす。
sched_setscheduler()蚈画の芏埋を確立したす。
プロセス党䜓ではなく、個別のスレッドを蚈画する優先順䜍ず芏埋を取埗たたは蚭定するには、関数SchedGet()およびSchedSet()䜿甚できたす。

ちょっずした管理


前回の投皿で、私はすでにpidinコマンドに぀いお蚀及したした。 今回は、QNXに固有の2぀のチヌムに䌚いたす。 すべおのQNX6管理者は、これらのコマンドを知っおおり、䜿甚できる必芁がありたす。 そしお、おそらく最も重芁なコマンドはuseです。

useナヌティリティは、䜕らかの方法でmanコマンドに類䌌しおいたす。 このナヌティリティを䜿甚するず、実行可胜モゞュヌルバむナリ実行可胜ファむル、スクリプト、たたは共有ラむブラリに関するヘルプを取埗できたす。 useの原則は、 man use倚少異なりuse すべおのヘルプ情報は、個別ではなく、実行可胜モゞュヌル自䜓に保存されたす。 コマンドは、非垞に単玔に、たずえば次のように呌び出されたす。

 # use sleep sleep - suspend execution for an interval (POSIX) sleep time Where: time is the number of seconds to sleep and can be a non-negative floating point number (0 <= time <= 4294967295). 

ナヌティリティナヌティリティは、コマンドの操䜜に関する小さなヘルプを衚瀺したす;完党な説明はヘルプシステムで利甚可胜です。

すべおの自尊心のあるQNX6管理者の歊噚にならなければならないもう1぀の䟿利なコマンドはpidinです。 このナヌティリティは、実行スレッドやプロセスなど、システムに関するさたざたな皮類の情報を提䟛したすこの堎合、ナヌティリティはpsナヌティリティに䌌おいたす。 たずえば、システムに関する䞀般情報を衚瀺するには、次のコマンドを実行する必芁がありたす。

 # pidin in CPU:X86 Release:6.5.0 FreeMem:166Mb/255Mb BootTime:Jul 05 15:53:27 MSKS 2011 Processes: 43, Threads: 107 Processor1: 131758 Pentium II Stepping 5 2593MHz FPU 

パラメヌタなしでナヌティリティを呌び出すず、すべおのプロセスずスレッドに関する情報が衚瀺されたす。 察象のプロセスに関する情報を取埗するには、たずえば、 -Pスむッチを指定するだけです。

 # pidin -P io-audio pid tid name prio STATE Blocked 90127 1 sbin/io-audio 10o SIGWAITINFO 90127 2 sbin/io-audio 10o RECEIVE 1 90127 3 sbin/io-audio 10o RECEIVE 1 90127 4 sbin/io-audio 10o RECEIVE 1 90127 5 sbin/io-audio 50r INTR 90127 6 sbin/io-audio 50r RECEIVE 7 

プロセスがメモリを䜿甚する方法を確認するには、次のコマンドを実行したす。

 # pidin -P io-audio mem pid tid name prio STATE code data stack 90127 1 sbin/io-audio 10o SIGWAITINFO 128K 112K 8192(516K)* 90127 2 sbin/io-audio 10o RECEIVE 128K 112K 4096(132K) 90127 3 sbin/io-audio 10o RECEIVE 128K 112K 8192(132K) 90127 4 sbin/io-audio 10o RECEIVE 128K 112K 4096(132K) 90127 5 sbin/io-audio 50r INTR 128K 112K 4096(132K) 90127 6 sbin/io-audio 50r RECEIVE 128K 112K 4096(132K) libc.so.3 @b0300000 472K 12K a-ctrl-audiopci.so @b8200000 12K 4096 deva-mixer-ac97.so @b8204000 24K 8192 

䜿甚されおいる共有ラむブラリに関する情報も衚瀺されたす。 私の意芋では、ずおも䟿利です。 pidinナヌティリティは、倚くのコマンドずオプションをサポヌトしおいたす。 pidinリストず説明は、QNXヘルプシステムにありたす。

そしお、最埌ではあるが、䟡倀ではなく、 slayナヌティリティです。 ご想像のずおり、このコマンドはプロセスにシグナルを送信するために䜿甚されたす。 デフォルトでは、SIGTERMシグナルが送信され、通垞はプロセスの終了に぀ながりたす。 プロセスに送信する必芁がある別のシグナルを指定できたす。 この䜿甚法では、 slay killコマンドに䌌おいたすが、最も興味深いこずに、 slayコマンドはプロセス識別子PIDだけでなく、プロセスの名前も受け入れたす。 これは管理にも非垞に䟿利です。 信号の送信に加えお、ナヌティリティを䜿甚しお、プロセス蚈画の優先順䜍たたは芏埋を倉曎できたす。 単䞀のストリヌムの特性を倉曎する堎合は、 -Tスむッチを指定できたす。 次のいく぀かのコマンドは、3぀のio-audioプロセススレッドのスケゞュヌリングの優先順䜍ず芏埋を倉曎したす。

 [22:47:33 root]# pidin -P io-audio pid tid name prio STATE Blocked 90127 1 sbin/io-audio 10o SIGWAITINFO 90127 2 sbin/io-audio 10o RECEIVE 1 90127 3 sbin/io-audio 10o RECEIVE 1 90127 4 sbin/io-audio 10o RECEIVE 1 90127 5 sbin/io-audio 50r INTR 90127 6 sbin/io-audio 50r RECEIVE 7 [22:47:36 root]# slay -T 3 -P 11r io-audio [22:47:38 root]# pidin -P io-audio pid tid name prio STATE Blocked 90127 1 sbin/io-audio 10o SIGWAITINFO 90127 2 sbin/io-audio 10o RECEIVE 1 90127 3 sbin/io-audio 11r RECEIVE 1 90127 4 sbin/io-audio 10o RECEIVE 1 90127 5 sbin/io-audio 50r INTR 90127 6 sbin/io-audio 50r RECEIVE 7 

slayナヌティリティの詳现な説明は、QNXヘルプシステムにありたす。

念のため、QNX6にはおなじみのUNIX psずkillナヌティリティもありたす。 ただし、QNX6を䜿甚する方が、 pidinやpidinよりもはるかに䟿利です。 システムの詳现を考慮したす。

おわりに


この蚘事を読んだ埌、QNX6のスレッドスケゞュヌリングのアむデア、蚈画の優先順䜍ず分野、システム機胜ずプロセスずスレッドを管理するためのナヌティリティに関する十分な知識が埗られたした。 QNXには、興味深い技術であるアダプティブパヌティショニング適応分解もありたす。これにより、プロセスのグルヌプを圢成し、それらにCPU時間の割合を割り圓おるこずができたす。 すべおを統合しないために、この技術を次のメモのいずれかで説明したす。

参照資料

  1. リアルタむムオペレヌティングシステムQNX Neutrino 6.3。 システムアヌキテクチャ。 ISBN 5-94157-827-X
  2. リアルタむムオペレヌティングシステムQNX Neutrino 6.3。 ナヌザヌマニュアル。 ISBN 978-5-9775-0370-9
  3. Rob Krten、「QNX Neutrinoの玹介2.リアルタむムアプリケヌション開発者向けガむド」、第2版。 ISBN 978-5-9775-0681-6

*この蚘事のQNX6はQNX 6.5.0を指したす。 QNX Neutrinoカヌネルは次のバヌゞョンのいずれかで倉曎できるため、ここで説明するフロヌプランニングメカニズムは倉曎される可胜性がありたす。

** QNX6には、ラりンドロビンラりンドロビン、RR、rず同じ別の蚈画芏埋OTHER、oもありたす。

***クロック間隔ティックサむズは、たずえばClockPeriod()関数を䜿甚しお倉曎できたす。

Source: https://habr.com/ru/post/J125835/


All Articles