caxapa.ru :: У тебя привычка обобщать все по самое некуда :) И в этом самом некуда - находить неразрешимые проблемы. Не бывает единого драйвера под разные OS и радикально разное железо.

LightElf (18.06.2020 22:49, просмотров: 944) ответил fk0 на A остальные что, будут вечно спать? Я забыл уточнить, но записи в буфере не фиксированного размера (логгер -- текстовые строчки, вроде очевидно). Да и посылаются в компорт может быть не по одной. Вместо одной ушедшей можно 5 новых записать, и наоборот. Будить нужно всех ожидающих. И потом, между моментом проверки (нет места) и засыпанием на семафоре запросто могло появиться свободное место. И наоборот, после получения сигнала семафора другой поток мог занять всё своими

У тебя привычка обобщать все по самое некуда :) И в этом самом некуда - находить неразрешимые проблемы. Не бывает единого драйвера под разные OS и радикально разное железо.

Вариант 1. Буфер заведомо больше, чем самая длинная строка лога. Достаточно частая ситуация. UART с DMA (типа того же STM32), буфер в килобайт. Разумная строка лога - в пределах 100 символов. Нужен один бинарный семафор.

Семафор взводится в обработчике прерываний DMA по условию "в буфере есть 100 свободных байт". Первый же поток хватает семафор, запихивает в буфер всю свою строку и отваливает. Остальные потоки обламываются. Когда в буфере освободится место - обработчик прерывания снова взведет семафор, самый приоритетный/первый/один из (в зависимости от того, как реализовано в OS) поток схватит семафор и отправит свою строку. И т.д.

Вариант 2. Буфер маленький, например UART с FIFO без DMA (типа LM3S, NUC970 и тыды). Нужен мутекс и примитив блокировки типа Block/Run. Поток захватывает мутекс, запихивает в FIFO сколько запихивается и блокируется. Обработчик прерывания по событию "в FIFO есть X свободных байт" будит этот поток, тот запихивает следующую порцию, снова блокируется и т.д. Когда отправит последний байт - отдаст мутекс. Мутекс схаватит следующий поток и айда вперед.

Оба варианта оборачиваются в некий единый интерфейс и получается "драйвер UART" для конкретной OS.

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

Ответить

- Я не обобщаю, я подвожу к сложности реализации такой элементарной сущности как условная переменная. Без которой нормально задачу не решить. Да, её можно построить на базе пары семафоров, причём один нужен в TLS (а в ThreadX есть TLS?), или можно сделать как в SDL, по семафору на каждого ждуна (что реально плохо выглядит когда их много -- я уже как-то писал про это). В данной задаче можно схалявить и сделать недоделку (не являющуюся полноценной условной переменной, но fk0(6968 знак., 19.06.2020 00:55, ссылка)
  - Ну вот опять ~~за рыбу деньги~~ попытка найти единое универсальное решение. Первое, что стоит сказать - на мелких процессорах системный вызов, как правило, легкий по тактам. Второе, чаще всего есть возможность просто и дешево сделать короткую критическую секцию, например запретив прерывания. Третье, там обычно нет SMP. Все это меняет развесовку описанных тобою проблем. LightElf(948 знак., 19.06.2020 02:13)
    - А какое должно быть решение? Можно подумать, что какие-то фундаментальные принципы в "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)

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