Микроконтроллеры

медленный и блокирующийся -- это контракт, интерфейс. А как он сделан -- не имеет значения. В этом суть ООП, что можно что-то проектировать без того, чтоб утонуть в деталях знания о всех уровнях. Связь между уровнями есть только в ограниченных пределах оговоренных контрактов.

Запрет прерываний -- выход только для CPU и ОС где нет разделения на супервизор и юзерспейс режимы, вроде мелких пиков. Но даже если, между "можно сделать" и "уже сделано" -- две большие разницы. Так сейчас где-то сделано, что прерывания запрещаются? Есть такие реализации атомиков в libgcc, например?

Вариант 1 именно что бажный: не выполнено условие задачи -- максимально использовать буфер, а не блокироваться при полупустом буфере (ключевое слово -- блокироваться, хоть блокировки запросто можно было избежать, ведь в буфере есть место). У тебя каждая запись начнёт, после первого затыка, требовать сигнализации семафора. Потому, что толпа потоков встанет в ожидание и на каждый отправленный пакет, условно, ты будешь будить ровно один поток, который условно тоже один пакет положит в буфер. Даже если всегда в буфере есть место, ты всегда постишь семафор после отправки очередного пакета, тебе теперь чтоб избавиться от очереди висящих на семафоре нужно отправить столько пакетов сколько потоков в очереди. И они будут долго там висеть, а другие будут без очереди херачить в буфер (потому, что место есть). Это бы работало, если бы сообщения в буфере имели одинаковый размер. Но размер по условиям задачи может варьироваться. И запросто вместо одного отправленного килобайтного сообщения влезет 50 шт. 20-байтных.