Вопрос чутка некорректный и вот почему. "Mutex" - понимается как
mutual exlusion вообще, в целом. Многие без достаточных на то
оснований полагают что Mutex это всенепременно объект "операционной
системы" и отсюда делается дальнейший вывод что гарантированно
нужна операционная система. Но это не так. Mutex это общее понятие,
никакой гарантии семантики или гарантированного интерфейса у этого
термина нет. В Microsoft операционке в API для межпроцессной
синхронизации существуют предлагаемые как API "мьютексы" (взаимодействующие для эффективности с шедулером потоков), но это ничего не значит, в остальных операционках это не так, и называться они могут "Lock"'и, например: pthread_mutex_lock() / ...unlock(), реализация потоков (и локов, т.е. мьютексов) также существует в виде линкуемых или компилируемых библиотек. Понятие "операционка" тоже весьма растяжимое, в ситуациях одна система - одна основная программа ("проект") операционка часто представляет собой линкуемую библиотеку.
IAR - среда, со своим компилятором, линкером, отладчиком, и местами со своими библиотеками, со своим API. Но они в стеке (бутерброде) абстракций лежат несколько не там, где тебе нужно. С одной стороны - ниже, более низкоуровнево, чем необходимо (компилятор, линкер). С другой стороны, выше. Тебе нужно было искать искомое не у IAR, а для начала у ARM: Google CMSIS-RTOS. Ну и дальнейший вариант поиска, это просмотреть код уже готовых rtos. Это вот то, с чего можно было начинать. В примере к Для STM8 нашел "Example of implementing a semaphore in C" дела обстоят не совсем хорошо. Они показывают использование реализованного ими слова __monitor, но временно отключать вообще все прерывания может привести к плохому, потому что событие вызывающее прерывание пролетит и ты его пропустишь. С другой стороны, надо очень внимательно разбираться как это делается, потому что "отключение прерываний" может быть чисто логическое, на уровне IAR и ничего страшного в этом нет.