caxapa.ru :: "В mainloop выгребаю из ringbuffer" - видимо без критической секции, если во время выгребания придет прерывание и запишет в буфер данные, то кирдык? запрещать прерывания надо бы на время чтения

NAUT (17.05.2020 10:56, просмотров: 825) ответил RxTx на Я пока что в командировке, так что "решено" это условно, временно. Я к тому так написал чтобы не ломали голову из-за меня, как бы не тратили энергию. Но если есть какие-то мысли, конечно пишите. Приеду домой, буду разбираться, трассировать времянки итд. "Решено" так: сделал код прерывания как можно более коротким, просто запись в ring buffer. Об этом писал здесь: и один из UART'ов у меня уже был так построен. Этот (отладочную консоль) я перевел, остался еще один,

"В mainloop выгребаю из ringbuffer" - видимо без критической секции, если во время выгребания придет прерывание и запишет в буфер данные, то кирдык? запрещать прерывания надо бы на время чтения

Ответить

- Не надо запрещать, поскольку именно эта схема "Один Писатель - Один Читатель" с двумя изолированными и "догоняющими" друг друга readpos и writepos переменными сравниваемыми в одном месте LockFree. RxTx(63 знак., 17.05.2020 11:15)
  - Ну, кагбэ, вопрос "че делать, если в буфере нет места" - нужно задавать до написания реализации ring buffer. Собственно вариантов четыре: LightElf(394 знак., 17.05.2020 21:47)
    - п. 2) это естественное поведение кольцевого буфера, новое при невычитанном через N=длине кольца затрет старое. Возможен п. 5) - RESET. п. 6) Подлежит обсуждению - когда стратегия записи одна, а стратегия чтения другая. Теперь смотря что понимается под "атомарным инкрементом". Прерывание и main loop это не тру потоки, прерывание и весь код в нем (если без извратов) будет "атомарным". Выполнится целиком и возвратится в основной код. - RxTx(17.05.2020 23:21)
    - Пункт 1 не вариант, пункт 4 тоже -- это говнокод. Пункт 3 -- черти что, зачем оно может быть нужно? Реальны варианты 2 и 5. 5) вывод блокируется до появления свободного места в буфере -- требует примитивов синхронизации. Зачем в варианте 2 атомарный инкремент, и инкремент чего? Указатель записи двигает только писатель, а указатель чтения двигает только читатель. Противоположная сторона в обоих случаях (читатель и писатель соответственно) только читают не свой указатель fk0(1028 знак., 17.05.2020 21:57)
      - Пункт 1) очень часто вполне пригоден, зря ты так. Например для тех же логов. Буфер не бесконечен, а останавливать программу "пока логгер не прочихается" - не самая красивая идея. Соответственно именно для логов вариант 3) может быть полезнее, чтобы хоть "последний выдох господина ПЖ" не потерять. В варианте 2 писатель должен двинуть и read_index и write_index. И вот для того, чтобы корректно двинуть read_index ему и нужен atomic_inc. Вариант 4 - самый простой и тупой, но не LightElf(116 знак., 17.05.2020 22:13)
        
        Вот самое забавное, когда отлаживаешься (от слова лажа :) ) таки надо вставать, пока логгер не прочихается. А то грозит тем что строчка "ram test failed, reset" успешно не будет записана... - RxTx(18.05.2020 00:07)
        
        На это я пойтить не могу. Такие баги надо обрабатывать уже после ресета. - LightElf(18.05.2020 00:25)
        
        На это я могу сказать - "Кокой унтюресный у тебя RESET. Ты правда считаешь что RESET должен так работать, оставляя что-то там в каком-то состоянии?" RxTx(47 знак., 18.05.2020 20:13)
        
        Хорошим тоном является выяснять причину Reset-а. Это почти не больно. Там спецуевый регистр присопливлен. - LightElf(30.05.2020 21:50)
        
        Если останавливать не вариант -- пункт 2. Ибо в варианте 1 непонятно что делать. Останавливаться и мигать лампочкой? С пропусками -- это варианты 2 и 3. "Последний выдох" и "новые данные затирают последние записанные" несколько противоречиво. Что имеется ввиду? И сколько последних записанных? Последний байт, строку? "Последний выдох" -- это по-моему именно вариант 2 (новые данные затирают самые старые не обработанные). В варианте 2 писатель не должен двигать fk0(895 знак., 17.05.2020 22:52)
        
        Согласен, чета я все смешал в кучу. Упущен существенный вопрос, что представляют из себя "новые данные". Ежели это просто очередной символ - то набор вариантов один. Ежели это как-то форматированный блок данных (например строки лога) - то варианты другие. По поводу ковыряний с индексами - согласен, тоже вариант. Особенно на современных процах - сделал индекс типа uint32_t и лишних битов хватит на любой разумный размер буфера. - LightElf(17.05.2020 23:55)
  - +1. Проблемы с детектированием наезда, на необработанные данные, обгона указателя чтения, можно решить, если использовать не указатели, а индексы -- тогда освободятся старшие биты, в которых можно хранить счётчик. Ну или если есть 64-битные атомики. А если потеря данных не допустима, то увы, нужен семафор и условная переменная. fk0(1191 знак., 17.05.2020 12:53, ссылка, картинка)

ARM, RISC-V контроллеры