ロシアの1つのRTOSの概要、パート6。ストリーム同期ツール

残念ながら、実際のマルチスレッドアプリケーションを開発する場合、すべてのタスクのコードを記述し、それらをスケジューラに接続し、単純に起動することは不可能です。



まずはバナリティーから始めましょう。タスクが多い場合、アイドルサイクルで実行するためにプロセッサー時間を無駄に使い始めます。 以前の出版物ですでに述べたように、現在何の関係もない（機器からのデータが来なかった、または他の組織上の理由で）すべてのタスクをブロックする必要があります。 プロセッサクロックには常にマイクロコントローラが搭載されていないため、実行するには、現在実行すべきタスクのみを設定する必要があります。



さらに、特定のリソース（特に機器）でタスクが互いに競合する場合があります。 マルチタスクの種類を検討する際に、SPIポートの競合の典型的なケースを既に検討しました（協調マルチタスクに切り替えることで部分的に解決されましたが、常に切り替えることはできません）。



そして最悪の場合はタスクの依存関係です。 多くの場合、1つのタスクの結果は別のタスクで使用されます。 明らかな例として、次のものを挙げることができます：温度センサーからの十分なデータを受信して​​平均化するまで、温度コントローラーのPID出力のデータを再計算することは無意味です。終端文字（行終端記号）が受信されるまで端末から。 そして、明白なものに加えて、依存症とそれらが生成する人種の多くの明白でないケースがあります。 初心者の開発者は、プログラムのアルゴリズムを直接実装するよりも、レースと戦うのに時間がかかる場合があります。



これらすべての場合において、同期オブジェクトは開発者の助けになります。 現在の出版物で、MAX MAX RTOSで使用可能な同期オブジェクトと関数を考えてみましょう。



前の部分を見たことがない人のために、リンク：



パート1.一般情報

パート2. RTOS MAXのカーネル

パート3.最も単純なプログラムの構造

パート4.有用な理論

パート5.最初のアプリケーション

パート6.スレッド同期ツール（この記事）

パート7.タスク間でデータを交換する手段

パート8.割り込みの処理

クリティカルセクション

ウォームアップするには、CriticalSectionクラスを検討します。 コンテキストの切り替えが受け入れられない領域をフレーム化するために使用されます。



クラスオブジェクトがスコープに表示されるとすぐに、優先度がMAX_SYSCALL_INTERRUPT_PRIORITY以下のすべての割り込みがブロックされます。 現在、この定数は5であり、デバイスおよびシステムタイマーからのすべての割り込みをブロックしますが、例外的な状況をブロックしません。



オブジェクトがスコープから外れると、割り込みレベルは入力前の状態に戻ります。 後者では、ネストされたクリティカルセクションの取得を心配する必要はありません。実際に機能するのは最初のセクションのみです。 外部以外はすべて不必要な作業を行います。 まず、許可された高レベルの割り込みを同じ割り込みに置き換え、終了するときに元の割り込みを復元すると、元の高のままになります。 埋め込まれたクリティカルセクションの最も外側を終了すると、低レベルが復元されます。 もちろん、ネストは関数が呼び出されたときに最も頻繁に取得されます。この関数にはクリティカルセクションもあります。



クリティカルセクションは割り込み優先度を変更する、つまりNVICをプログラムするため、特権モードコードでのみ使用する必要があります。



例について考えてみましょう（ピンク色で強調表示された領域は、クリティカルセクションによって保護されています。ここでは、コントロールがタスクから削除されないことが保証されています）









もちろん、オブジェクトのスコープは常に中括弧で制限できます。









クリティカルセクションには何を含める必要がありますか？ たとえば、たとえば、いくつかの変数をアトミックに変更する必要がある操作（上記の例はまさにそれを行います）。 1つのタスクが読み取り、他のタスクが書き込みを行うさまざまなリストやその他のものには、アトミックアクセスが必要になる場合があります。



しかし、それほど明白なものはありません。 あるタスクで増加し、別のタスクで減少する特定のカウンターがあるとします。 それは非常にアトミックな操作のようです



cnt ++;



しかし、高レベル言語のレベルではアトミックです。 アセンブラレベルでは、読み取り-変更-書き込み操作に分割されます。



26: cnt++;

0x08004818 6B60 LDR r0,[r4,#0x34]

0x0800481A 1C40 ADDS r0,r0,#1

0x0800481C 6360 STR r0,[r4,#0x34]







値（忠実度、たとえば10）が既にレジスタr0に入力された後、スケジューラが制御を別のタスクに転送するとします。 また、10の値をカウントし、9を入力して値を減らします。次に、制御が現在のタスクに戻ったときに、変数ではなく、レジスターr0にあるものに10を追加します。 11になります。カウンターの値が歪んでいます。



それはそのような状況から保護するためだけであり、クリティカルセクションは非常に適しています。

 { CriticalSection cs; cnt++ }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、NVICを使用するオーバーヘッドも念頭に置いておく必要があります。3つではなく、はるかに多くのアセンブラーコマンドになるためです。



27: CriticalSection cs;

0x0800481A 4668 MOV r0,sp

0x0800481C F7FEFCE8 BL.W _ZN4maks15CriticalSectionC2Ev (0x080031F0)

28: cnt++;

0x08004820 6B60 LDR r0,[r4,#0x34]

0x08004822 1C40 ADDS r0,r0,#1

29: }

0x08004824 6360 STR r0,[r4,#0x34]

0x08004826 4668 MOV r0,sp

0x08004828 F7FEFDA0 BL.W _ZN4maks19InterruptMaskSetterD2Ev (0x0800336C)







これはシステムサブルーチンの内容をカウントするものではありません...読者がその複雑さを想像できるように、ここに最初の1つだけを示します。



0x080031F0 B510 PUSH {r4,lr}

0x080031F2 2150 MOVS r1,#0x50

0x080031F4 F000F8AE BL.W _ZN4maks19InterruptMaskSetterC2Ej (0x08003354)

0x080031F8 4901 LDR r1,[pc,#4] ; @0x08003200

0x080031FA 6001 STR r1,[r0,#0x00]

0x080031FC BD10 POP {r4,pc}







あなたが見ることができるように-これはまだ最大のネストではありません...一方、それはまだ悪の少ないです。 頻繁に出入りするクリティカルセクションに夢中にならないでください。



クリティカルセクションは非常に強力ですが、潜在的に危険なツールです。スコープから外れるまでマルチタスクがオフになるためです。 理想的には、数行のみをロックする必要があります。 サイクルの存在は、遅延時間を大幅に増加させ、関数を入力します-さらには（プログラマーがこれらの関数に費やされた時間を十分に認識していない場合）さらに、ある種の機器で作業することは非常に潜在的に危険なことです。 プログラマに、周波数10 MHzのSPIバスでの2バイトの送信中にコンテキストスイッチがないことを保証することを決定させます。 1ビットの周期は100 nsです。 16ビット-1.6μs これは完全に受け入れられる結果です。 次のタスクで失われるのはこのセクションだけです（一般的に、これはスケジューラーの時間に匹敵します）。 しかし、250キロビット/秒の速度で20文字のUART文字列を介して送信する場合、20 * 10 * 4μs= 0.8ミリ秒かかります。 つまり、タスクタイムクォンタムの終わり近くでプロセスを開始すると、次のタスクのクォンタム全体のほとんどを「食べる」ことになります。



一般に、クリティカルセクションのメカニズムは非常に強力ですが、それを使用するプログラマーは、リアルタイムでシステムの動作を保証するすべての責任を負います。



繰り返しますが、他のリソースを待機している機能を使用して、クリティカルセクションにあるタスクを安楽死させないでください。



最も単純な例を考えてみましょう。 ポートの状態を変更する既知のタスクで、ロック付きの遅延関数を定期的に呼び出します。

  virtual void Execute() { while (true) { GPIOE->BSRR = (1<<nBit); Delay (5); GPIOE->BSRR = (1<<(nBit+16)); Delay (5); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

通常の蛇行を与えます：







クリティカルセクションを追加









まったく異なる信号を受け取ります







ズームイン-信号周期が完全に間違っています...







一般に、クリティカルセクションは強力なツールですが、アクション（または少なくとも、実行するすべてのステップを制御する）を認識している場合にのみ使用してください。



ウォームアップは何とか引きずられました。 最も単純なものは、たくさんのシートに広がっています。 さて、ロジックがもう少し複雑になりましたが、必要なテキストは少なくなりました。バイナリセマフォです。

バイナリセマフォ

むかしむかし、鉄道ではセマフォが積極的に使用されていました。 彼らには2つの州がありました：上げられた-列車は動くことができます。 停止-列車は待たなければなりません。 まあ、ディスパッチャはそれを上げ下げしました。 そして、ここでは、いくつかのタスク（複数のタスク）がロープを引っ張って（ディスパッチャとして動作）、いくつかのタスク（複数のタスク）がパスが開かれるのを待ちます。 同時に、保留中のタスクはブロックされます。つまり、時間を浪費しません。







このようなセマフォは、BinarySemaphoreクラスによって実装されます。



クラスコンストラクターには、セマフォの初期状態を設定する必須引数が含まれています



明示的なBinarySemaphore（bool is_empty = true）



さらに、バイナリセマフォの機能のみを検討します（事実は、それが単純なセマフォの相続人であり、以下でその機能をすべて検討することです）。



セマフォを通過するタスクは、 Wait（）関数を呼び出す必要があります。 この関数の引数はミリ秒単位のタイムアウトです。 指定した時間内にタスクのロックが解除された場合、関数はResultOkを返します 。 したがって、タイムアウトが発生した場合 、関数の結果はResultTimeoutになります。 関数が「停止する」まで待機する必要がある場合、 INFINITE_TIMEOUTに等しいタイムアウト値を渡す必要があります。



関数がゼロのタイムアウト値で呼び出されると、即座に制御を返しますが、結果（ ResultOkまたはResultTimeout ） からセマフォが開いているか閉じているかは明らかです。



割り込みから呼び出された場合、タスクのブロックは不可能であるため、ゼロ以外のタイムアウトでは、関数の結果はResultErrorInterruptNotSupportedになります。 ただし、タイムアウトがゼロの場合、関数は割り込みから呼び出すこともできます。



関数がResultOkの結果を返す場合、セマフォは自動的に閉じます。



既に述べたように、いくつかのタスクはセマフォを一度に待つことができます。 この場合、最初に見落とされる「ラッキーなもの」の選択は、次のように実行されます。待機リスト内のタスクは、優先順位の降順で、同じ優先順位で、 Wait（）関数を呼び出した順番になります。



セマフォを開くには、 Signal（）関数が使用されます。 セマフォがすでに開いている場合は、 ResultErrorInvalidStateの結果を返します。それ以外の場合は-ResultOkを 返します。 MAX_SYSCALL_INTERRUPT_PRIORITYよりも高い優先度を持つ割り込みから関数を呼び出すことはできません。

セマフォ

正直なところ、私はこの名前が嫌いです。 この同期オブジェクトを「Zavkhoz」と呼ぶ方が正しいでしょうが、伝統に反論することはできません。 セマフォと呼ばれるすべての場所で、RTOS MAXも例外ではありません。 単純なセマフォ（またはサプライマネージャ）とバイナリセマフォの違いは、カウント（リソースをウェアハウスに入れる）できることです。 少なくとも1つのリソースがあります-タスクはパスできます（リソースの数は減少します）。 リソースなし-タスクは少なくとも1つが表示されるまで待機します。







このようなセマフォは、リソースを割り当てる必要があるときに役立ちます。 たとえば、USBにデータを出力するために4つのバッファを開始しました（このバスはバイトでは動作しませんが、バイトの配列で動作するため、バッファにデータを準備するのが最も便利です）。 したがって、作業タスクは空きバッファーがあるかどうかを判別できます。 ある場合は、記入してください。 いいえ-USBで動作するものが少なくとも1つを送信してリリースするまで待ちます。 一般に、1つではなく複数のリソースがどこかに割り当てられている場合、それらの配布をサプライマネージャ（または、従来の命名法ではセマフォ）に割り当てるのが最も便利です。



したがって、このオブジェクトはSemaphoreクラスで実装されます。 バイナリセマフォとの違いを考慮してください。 まず、彼はわずかに異なるコンストラクタを持っています



セマフォ（size_t start_count、size_t max_count）



最初のパラメーターは、最初にボックスに入れるものの数、2番目のパラメーター-このボックスの寸法です。 作業の開始時にリソースの完全な不足を宣言し、それらを追加することは便利です（思い出すように、 Signal（）関数を呼び出します）。 場合によっては、逆に、初期リソースが最大にロードされてから使用されることもあります。 ブートストラップが不完全な他のオプションも可能ですが、読者は必要なときにこれを思い付くでしょう。



Signal（）関数は、それぞれリソースカウンターを増やします。 最大値に達すると、 ResultErrorInvalidStateを返します。 繰り返しになりますが、MAX_SYSCALL_INTERRUPT_PRIORITYより高い優先度の割り込みから関数を呼び出すことはできません。



リソースの数がゼロに等しくない場合、カウンターを減らしながら、 Wait（）関数はタスクをスキップします。 リソースがない場合、タスクはSignal（）関数を介して返されるまでブロックされます。 繰り返しますが、割り込みからこの関数はタイムアウトなしでしか呼び出せないことを思い出してください。



次に、バイナリの場合に意味をなさない関数を考えます。



GetCurrentCount（）は、リソースカウンターの現在の値を返します



GetMaxCount（）は、可能な最大カウンター値を返します（セマフォーが別のタスクを作成した場合-その特性を判別するのに役立つ場合があります）

ミューテックス

このオブジェクトの名前は、「相互排他的」という言葉に由来しています。 つまり、システムは1つのリソースへの相互排他的アクセスを提供します。 セマフォでいくつかのタスクが解決を待っていて、他のタスクがセマフォを開いている場合、この場合、誰もがリソースをキャプチャしようとしますが、システム自体がそれを提供します。



簡単に言えば、ミューテックスの本質は「最初に起きたのは誰ですか-それとスリッパ」というフレーズで説明できます。 保護されたオブジェクト-「スリッパ」があります。 夫は目を覚まし、彼らに尋ねました-システムは、それらを分割されていない使用のために彼に与えました。 妻と息子が尋ねた-彼らはブロックされました。 夫がシステムにスリッパを返すとすぐに、妻はそれらを受け取りました。 彼女は戻った-息子を受け取った。 彼は戻りました-オブジェクトはフリー状態になり、次のリクエスターは待機せずに再びそれらを受け取ります。



マイクロコントローラでは、この方法で保護する必要のある素晴らしいリソースは、いくつかのタスクがポートを介して機能しようとしている場合、ポート（SPI、I2Cなど）です。 いくつかの異機種デバイスを同じ物理チャンネルに接続できることをすでに検討しています。たとえば、クラシックテレビでは、1つのI2Cバスにビデオプロセッサ、オーディオプロセッサ、テレテキストプロセッサ、チューナーが存在する可能性があります-それらは異なるタスクによって処理される可能性があります。 なぜBSYビットのリセットを待つためにCPU時間を浪費するのですか？ さらに、とにかく、衝突が可能です。 BSYポートのビットを排他的に分析し、それらを段階的に実行する3つのタスクの作業を検討します。







ご覧のとおり、ステップ7では、2つのタスクがすぐにバスを制御しようとしています。 ミューテックスで保護されていれば、これは起こりませんでした。 さらに、条件付きステップ1（実際、これはタスク2またはタスク3のいずれかがブロックされる大量のステップです）で、タスクは時間を浪費していました。 Mutexはこの問題も解決します-待機中のタスクはすべてブロックされます。



開発者がミューテックスに夢中になりすぎて、タスクがミューテックスを数回キャプチャすることがある場合があります。 もちろん、ほとんどの場合、これはネストされた関数で発生します。 関数1はミューテックスをキャプチャし、制御は関数2から関数3に、そこから関数4（1年前に記述）に渡され、同じミューテックスをキャプチャしようとします。 このような場合、ブロッキングを回避するために、再帰的なmutexを作成する必要があります。 1つのタスクでそれらを繰り返しキャプチャできます。 彼が捕らえられた回数だけ解放することが重要です。 Windows OSでは、すべてのミューテックスは再帰的ですが、弱いマイクロコントローラーに対するこのようなアプローチは、リソースの不当な支出につながるため、デフォルトでは、ミューテックスはMAX MAX RTOSで再帰的ではありません。



Mutexクラスの主な機能を検討してください。 まず、そのコンストラクタ



ミューテックス（boolrecursive = false）;



コンストラクター引数は、タイプを決定します-再帰的かどうか。



Lock（）関数はミューテックスをキャプチャします。 タイムアウト値は引数として渡されます。 いつものように、特別な値を設定できます-ゼロタイムアウト（待機せずに即時出力）またはINFINITE_TIMEOUT （勝利まで待機）。 ミューテックスがキャプチャできた場合、ResultOkが返されます。 タイムアウトが経過すると、結果ResultTimeoutが返されます。 非再帰的なミューテックスをキャプチャしようとすると、結果はResultErrorInvalidStateになります。 ミューテックスは割り込みでキャプチャできません。 これを行おうとすると、結果はResultErrorInterruptNotSupportedになります。



ロック解除（）関数-ミューテックスを解放します。 したがって、保護されたセクションの実行の最後に呼び出す必要があります。



IsLocked（）関数を使用すると、ミューテックスをキャプチャするか、キャプチャせずに解放するかを決定できます。 プリエンプティブマルチタスクでは、結果は分析される前でも関連性を失う可能性がありますが、協調マルチタスクでは、この機能が役立つ場合があります。



今、優先度の継承などについて話す価値があります。 システムに通常の優先度を持つタスクA、高優先度を持つB、および高優先度を持つCがあるとします。 タスクBとCがブロックされ、Aがこの時点でミューテックスをキャプチャできたとします。 それをグラフィカルに描画して、タスクを互いの上に配置します（優先度が高いほど、図のタスクが高くなります）







これで、タスクCのロックが解除されました。 もちろん、最高の優先順位を持ち、それが実現し始めました。 そして、彼女も同じミューテックスをキャプチャするとします。







しかし、ミューテックスはタスクAを所有しています！ 通常のロジックでは、ビジーになると、タスクCは解放されるまでブロックされます。 そして突然、タスクBのロックが解除されました（他のリソースを待機させ、解放されました）。 その優先度はAの優先度よりも高いため、正確に実行されます（つまり、タスクB）







何がありますか？ 優先度の高いタスクCは、ミューテックスが解放されるのを待っているため実行できません。 しかし、現在の所有者は、mutexの所有者よりも優先度の高いタスクに取って代わられますが、優先度は低く、比較的不公平にブロックされたタスクであるため、待機できません。



これを防ぐために、所有権の時点でミューテックスの所有者には、現在彼を待っているタスクの最高タスクの優先度が割り当てられます。 このようなメカニズム（優先度継承）により、ミューテックスが解放される瞬間を概算できます。







優先度の継承中にタスクAが通常の優先度を持つタスクEとも相互作用すると、この相互作用が失われるため、この事実は非常に重要です。 残念ながら、これでは何もできません（RTOSの標準コンセプトのフレームワーク内で）。これは、プログラムを設計するときに単純に考慮されるべきです。

ミューテックスガード

古典的なアルゴリズムプログラミングには、任意のアルゴリズムで1つの入力と1つの出力が含まれます。 しかし、この原則の狂信的な規定は、テキストの不当な複雑化と読みやすさの低下につながるような実践です。 次の擬似コードを見てみましょう。

 m_mutex.Lock(); switch (cond) { case 0x00: .... return ResultCode1; case 0x02: .... return ResultCode2; case 0x0a: .... return ResultCode3; case 0x15: .... return ResultCode4; } .... m_mutex.Unlock();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、ここで関数を終了する前に、mutex.Unlock（）を体系的に配置する必要があります。 また、大規模なアルゴリズムには、このようなセクションが多数存在する場合があります。 そして、それらを追加できます。 遅かれ早かれ、プログラマはミューテックスをどこかでロック解除することを忘れ、プログラムはフリーズします。 そしてこれは、人類が夜眠れなかったという事実にもかかわらず、一般にPLOを発明し、特にクラスのデストラクタを発明しました！



ミューテックスガードは、デストラクタが使用することだけを行います。 インターフェース部分のこのクラスには、コンストラクターしかありません。 プログラマーガイドからその説明をコピーします。

明示的なMutexGuard（Mutexとmutex、bool only_unlock = false）;



引数：

• mutex-mutexへの参照。
• only_unlock –値がtrueの場合、mutexはコンストラクターにキャプチャされません。 ミューテックスは、Lock（）メソッドの明示的な呼び出しによってすでにキャプチャされていることが理解されます。

ミューテックスはコンストラクタに渡される必要があります。 彼は捕らえられます。 そして、ミューテックスガードが視界から離れた瞬間に彼は解放されます。 したがって、前の例は次のように書き換える必要があります。

イベント

セマフォとミューテックスは通常、特定のリソースを使用するときにタスクの競合を排除するために使用されますが、ロックを解除する条件ができるまでタスクをブロックする必要がある場合があります。 典型的なシナリオ-割り込みが発生し、ハンドラー関数が遅延処理の優先度の高いタスクに信号を送り、何らかのタスクを実行する必要があることを通知します。 イベントを使用すると、このメカニズムを実装できます。



前の段落を読んだ後、イベントは単にセマフォを複製しているように見えるかもしれません。 しかし、これはそうではありません。 違いを見てみましょう。



最初の違い：イベントは、それを待っている人にのみ影響します。 現時点でイベントに受信者がいない場合、どこにも行きません。 イベントの発生後すぐに、誰かがそれを待ち始めます-それはブロックされます。 ロック解除は、次のイベントでのみ発生します。 誰も時間がなかった-彼は遅れていた。 私たちが思い出すように、セマフォは、反対に、誰かがそれを待っていたかどうかにかかわらず、とにかく開きます。 そして、セマフォを最初に渡すものはスキップされます。



2番目の違いは、複数のタスクがセマフォのオープンを待機している場合、そのうちの1つだけがロック解除されます。 残りは次のオープンを待ちます。 イベントは、その発生を待機していた全員のロックを解除するときにモードに設定できます。 つまり、待機中のすべてのタスクは「ブロック」状態から「アクティブ」状態の誰かに転送され、最も幸運なタスクは「実行中」状態に転送されます。



残り-イベントのロジックは、バイナリセマフォのロジックに似ています。



クラスコンストラクター：



イベント（bool broadcast = true）;



ブロードキャストパラメータは、イベントの通知を待っている受信者に通知するルールを設定します。 true –それを待っているすべてのタスクがロック解除され、false – 1つのタスクのみがロック解除されます。これは、このイベントを待っているキューの最初のタスクです。



Raise（）関数はイベントをディスパッチします。 MAX_SYSCALL_INTERRUPT_PRIORITYよりも高い優先度を持つ割り込みから呼び出すことはできません。



Wait（）関数は、以前に検討された同期オブジェクトと同じ名前の関数によってすでによく知られています。また、タイムアウト引数があります。同様に、タイムアウトはゼロまたはINFINITE_TIMEOUTにできます。この関数は、割り込みから呼び出すことはできません。

同期オブジェクトの使用例

残念ながら、同期オブジェクトが使用される単純で美しい例を作ることは不可能です。シンプルなものはすべて、関数呼び出しの例のデモンストレーションになります。実際に適用できるものは、あまりにも多くのボリュームを占有します。それらを説明するには長い時間がかかり、読者は2ページ目のスレッドを失い、他の28のページは誰にも読まれません。したがって、そのような作品を書くことは控えます。



計画された第3部では、CNCマシン用の大規模プログラムの適応の説明が表示されます。そのための例を残します。そして、練習を切望する人には、OSの単体テストをお勧めできます。これらは、ディレクトリ... \ maksRTOS \ Source \ Tests \ Unit testsにあります。ホストされているディレクトリのリストは次のとおりです



。BinarySemaphore

Event

MessageQueue

Mutex

MutexGuard

スケジューラ

セマフォ



ベストプラクティスの例は思いつきにくいです。あなたの研究を楽しんでください（ただし、まれな読者はテストの第1四半期の終わりに到達するとの意見があります）。