割り込みが無効になっているときにコンテキストを変更できないシステムがあると仮定すると、 enable() をいつ呼び出すかを注意深く追跡していれば、問題はありません。
以下のコメントで説明している使用法では、割り込みサービス ルーチン内からこれらのセクションを使用する予定です。主な用途は、優先度の高い割り込みが ISR の特定の部分で実行されるのをブロックすることです。
これらのネストされた ISR のスタックの深さを考慮する必要があることに注意してください。割り込みから戻る前に割り込みを有効にすると、ISR で割り込みが有効になります。
他の回答について: enable() のスレッド セーフの欠如 ( によるif(IrqCounter > 0)
) は問題ではありません。これは、enable() コンテキスト スイッチにいるときはいつでも、割り込みがオフになっているために既に無効になっているためです。(何らかの理由で無効化/有効化のペアが一致しない場合を除き、その場合は他の問題があります。)
唯一の提案は、実行時チェックの代わりに有効に ASSERT を追加することです。無効にしなかった割り込みを有効にしてはならないからです。
void EnableIRQ()
{
ASSERT(IrqCounter != 0) //should never be 0, or we'd have an unmatched enable/disable pair
IrqCounter--; //doesn't matter that this isn't thread safe, as the enable is always called with interrupts disabled.
if(IrqCounter == 0)
{
__enable_irq();
}
}
save(); disable(); restore();
割り込みを操作するたびにOSのデータの一部を追跡する必要がないので、テクニックよりもリストしたテクニックを好みます。ただし、いつ (直接または間接的に) ISR から enable() を呼び出すかを認識する必要があります。