タスク数=2のMCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコードの後半2プロジェクト、MutexとSemaphoreを説明します（前半は、前稿参照）。
FreeRTOSサンプルコード：タスク数＝2
| Project | Tasks | heap_ | Additional FreeRTOS APIs | Additional Comments |
| freertos_mutex | 2 | 4 |
xSemaphoreCreateMutex |
並列動作の共有リソース同期/競合制御。taskYIELDは要注意！ Mutexのセマフォ作成は、 xSemaphoreCreateMutex。 Semaphoreのセマフォ作成は、xSemaphoreCreateBinary。 |
| freertos_sem | 1+3 | 4 |
xSemaphoreGive |
※Freertos_semはタスク数4個。実質はproducer_taskとconsumer_taskの2個。
FreeRTOS Project：freertos_mutex
RTOSソフトウェアのメリットは、複数タスクが「完全に並列動作」することです。ただし、副作用として、共有リソースのアクセス競合が生じます。サンプルコードの場合はIDE Console出力で、その他にUARTやIOポートなど多くの共有リソースがMCUにはあります。
この共有リソースへのセクセス競合を防ぐ手段がミューテックスです。共有リソース使用前に他タスクの使用/未使用を検出し、未使用時のみ利用、利用後は、使用権を戻す操作（xSemaphoreGive）をします。
仮にミューテックス機能が無ければ、英字と数字が混ざった出力になり、使い物になりません。
並列動作のRTOSに、Mutexは必須機能です。
注意点は、Consoleへ部分出力後のtaskYIELDです。
F3クリックで調べましたがtaskYIELDの理由は、筆者には不明です。だだし、コメントを読むとFreeRTOSインプリメント依存部分なので、そのまま弄らない方が良さそうです。共有リソース利用中には、taskYIELDが必要と覚えておけば（とりあえず）良いとします。
※本調査の目的は、ベアメタルCortex-M4テンプレート開発へのRTOS機能応用であって、FreeRTOS自身ではないので、この程度で留めていきます👍。
共有リソース使用検出APIは、xSemaphoreTakeです。前稿freertos_ticklessプロジェクトの割込みISRと処理タスク同期に用いたAPIと同一です。差分は、セマフォ自体の作り方が異なります。ミューテックスの場合は、xSemaphoreCreateMutex、セマフォの場合は、xSemaphoreCreateBinaryです。
違いは、初期値です。ミューテックスは、初期値が使用可能（pdTRUE）になりますが、セマフォは、初期値が使用不可です。どちらも、並列動作タスク間の同期/競合制御として、同じAPI：xSemaphoreTakeを使っているということです。
FreeRTOS Project：freertos_sem
前稿freertos_ticklessで示したISRと処理タスクのセマフォ同期とは別の使用例が、freertos_ semプロジェクトです。同期というより、むしろ排他制御にセマフォを使った例です。
このプロジェクトは、これまでのサンプルコードで最も多い４タスク：1（producer_task）+3（consumer_task）を生成し、2個のセマフォ（xSemaphore_producerとxSemaphore_consumer）を使い、1個のアイテムを4タスク間で利用する例です（Doc>freertos_sem_example.txtによるとランデブーモデル同期と言うようです）。
1個の（共有）アイテムは、元々produser_taskが持っており、cunsumer_taskへその使用権を与えます（L119:xSemaphoreGive→xSemaphore_consumer）。
並列動作中の3個cumsumer_taskのどれかがこの使用権を取得します（L143:xSemaphoreTaka←xSemaphore_consumer）。使用後は、produser_taskへ使用権を返却します（L141:xSemaphoreGige→xSemaphore_producer）。
produser_taskは、cunsumer_taskの使用権返却を待っており（L121: xSemaphoreTaka←xSemaphore_producer）、返却後、再び最初に戻ってcunsumer_taskへ使用権を与えます。
cunsumer専用セマフォがxSemaphore_consumer、producer専用セマフォがxSemaphore_producerで、それぞれを図示したようにやり取りしながら4タスクが動作します。
ベアメタル風に、ランデブーモデル同期：synchronized in bilateral rendezvous modelを解説すると上記のようになります。
ソースコード上では、どのcumsumer_taskが共有アイテムを獲得するかは不明ですが、評価ボード実行結果は、常にConsumer 0→1→2→0･･･の順番でした。3個のcumsumer_taskプライオリティが同一の時は、生成順に1個のアイテム共有ができるようです。
FreeRTOSサンプルコード：タスク数＝2（後半）の調査結果
- FreeRTOSタスク並列動作副作用の共有リソースアクセス競合回避手段に、ミューテックスがある
- MCUXpresso54114 のFreeRTOS共有リソース利用途中には、taskYIELDが必要
- 初期値（pdTRUE）の有無が、ミューテックス作成とセマフォ作成で異なる
- バイナリセマフォの排他制御利用例に、ランデブーモデル同期がある
- メモリ使用法は、heap_4を利用
FreeRTOSデバイス依存開発ノウハウ
筆者のOS：Operating System利用アプリケーションソフト開発経験は、Windows PCのみです。Windows OSは、リアルタイム性はありません。そのおかげで、PCアプリケーションソフト開発時に、他タスクへの影響、プライオリティなどは考慮せずに比較的簡単に開発ができました。
ミューテックスやセマフォを利用した覚えもありません。もちろんファイルなどの共有リソースには、それなりのアクセス手順があり、それに従って開発すれば特に問題はありません。
一方MCUでOS利用の場合は、リアルタイム性は無視できません。限られたMCU能力を上手く利用するためのデバイス依存開発ノウハウが、メモリ使用法：heap_4やtaskYIELDだと思います。
これらノウハウは、ソースコード上では解りにくい代物です。また、文章記述できる量も限られます。
これには、評価ボード上でソースコードのパラメタを変えた時の挙動変化を開発者自身がつかんで習得する方法が効率的です。LPCXpresso54114（Cortex-M4/M0+ 100MHz、256KB Flash、192KB RAM）評価ボードは、入手性もよく低価格（約3400円）です。無償LPCXpresso IDEとともにご利用いただければ、本稿やFreeRTOSがより解り易くなります。
PS：FreeRTOSの最新版V10.3.0が2020年2月7日に公開されました。詳細は、リリースノートをご覧ください。