caxapa.ru :: Ну вот опять за рыбу деньги попытка найти единое универсальное решение. Первое, что стоит сказать - на мелких процессорах системный вызов, как правило, легкий по тактам. Второе, чаще всего есть возможность просто и дешево сделать короткую критическую секцию, например запретив прерывания. Третье, там обычно нет SMP. Все это меняет развесовку описанных тобою проблем.

LightElf (19.06.2020 02:13, просмотров: 969) ответил fk0 на Я не обобщаю, я подвожу к сложности реализации такой элементарной сущности как условная переменная. Без которой нормально задачу не решить. Да, её можно построить на базе пары семафоров, причём один нужен в TLS (а в ThreadX есть TLS?), или можно сделать как в SDL, по семафору на каждого ждуна (что реально плохо выглядит когда их много -- я уже как-то писал про это). В данной задаче можно схалявить и сделать недоделку (не являющуюся полноценной условной переменной, но

Ну вот опять ~~за рыбу деньги~~ попытка найти единое универсальное решение. Первое, что стоит сказать - на мелких процессорах системный вызов, как правило, легкий по тактам. Второе, чаще всего есть возможность просто и дешево сделать короткую критическую секцию, например запретив прерывания. Третье, там обычно нет SMP. Все это меняет развесовку описанных тобою проблем.

Вариант 1 не идеален (не бажный, а не очень эффективный), с другой стороны ты же не хочешь, чтобы куча непрерывно сыпящихся коротких сообщений, не давали другому потоку отправить свою камасутру с иллюстрациями? Как ни изгаляйся, пока он свои 100 байт не отправит - всем остальным стоять-бояться. Суть в том, что либо в буфере есть место для пиковых объемов, либо кому-то все равно придется стоять.

Вариант 2 определяется возможностями железа. Если у данного конкретного UART-а есть FIFO 64 байта и нет DMA - то хоть усрись, будешь дробить посылку на куски и не суть важно, как это будет делаться. Может из прерывания, может пробуждением и усыплением потока. Можно перейти к варианту 1, эмулируя DMA высокоприоритетным прерыванием. Но хорошего варианта тут просто нет. Не устраивает - значит логировать по UART-у на данном процессоре не выйдет, надо брать другой интерфейс, другой процессор или делать бинарный лог, 16 байт на событие хватит всем :)

Не надо делать мне как лучше, оставьте мне как хорошо

Ответить

- А какое должно быть решение? Можно подумать, что какие-то фундаментальные принципы в "computer science" чем-то отличны в зависимости от фирмы выпустившей микропроцессор. Может и не UART вовсе, а TCP/IP, и не микроконтроллер, а Core I9. Суть от этого не меняется. А ты хочешь сказать, мол в зависимости от того какой глубины UART в МК всё кардинально меняется... На верхнем уровне абстракции ничего о реализации нижнего знать не положено. Принято, что есть некий метод write, fk0(1601 знак., 19.06.2020 02:49)
  - Ну вот есть у тебя абстракция write, пользуй ее и не ломай голову как она внутри устроена. Конкретная реализация write будет зависеть от OS, а конкретная реализация драйвера UART - от конкретного железа. А если не UART, а Ethernet - там будут другие реализации и другие драйвера. Будет ли там условная переменная, два семафора или отдельный сопроцессор с блекджеком и программистками - это вопрос конкретной реализации, а не фундаментальных принципов. LightElf(2323 знак., 19.06.2020 12:42)
    - В таком варианте вместо запрета прерываний следует использовать мьютекс -- они для этого и существуют. Причём мьютексов связанных с разными и независимыми защищаемыми наборами данных может быть много, а флаг прерываний -- один всего. Мьютекс более эффективен. Более того, запрещать прерывания более чем несколько тактов -- дичь! Вопрос же не как критическую секцию сделать, а как сделать атомик (на основе которого уже можно сделать тот же мьютекс или критическую секцию). fk0(2371 знак., 19.06.2020 15:27)
      - Ну так никто не запрещает реализовать атомик через запрет прерывания, если подходящих инструкций процессору не завезли. Получатся как раз те самые несколько тактов. В FreeRTOS-е можно блокироваться из критической секции, система отслеживает такую ситуацию. - LightElf(23.06.2020 16:32)
      - Ввиду не установки драйвера rookie.sys на сервере сахары пост читать можно только кликнув на него... - fk0(19.06.2020 15:30)
        
        Имеешь в виду, что кнопочка "развернуть [под]ветку" не работает? У меня на старом FF 52 - тоже не работает. - Toчкa oпopы(19.06.2020 16:35)
  - Интересно, если использовать язык Rust, эти проблемы останутся? =AK=(58 знак., 19.06.2020 12:41)

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