ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Пятница
22 ноября
1005401 Топик полностью
fk0, легенда (17.05.2020 22:52, просмотров: 795) ответил LightElf на Пункт 1) очень часто вполне пригоден, зря ты так. Например для тех же логов. Буфер не бесконечен, а останавливать программу "пока логгер не прочихается" - не самая красивая идея. Соответственно именно для логов вариант 3) может быть полезнее, чтобы хоть "последний выдох господина ПЖ" не потерять. В варианте 2 писатель должен двинуть и read_index и write_index. И вот для того, чтобы корректно двинуть read_index ему и нужен atomic_inc. Вариант 4 - самый простой и тупой, но не
Если останавливать не вариант -- пункт 2. Ибо в варианте 1 непонятно что делать. Останавливаться и мигать лампочкой? С пропусками -- это варианты 2 и 3. "Последний выдох" и "новые данные затирают последние записанные" несколько противоречиво. Что имеется ввиду? И сколько последних записанных? Последний байт, строку? "Последний выдох" -- это по-моему именно вариант 2 (новые данные затирают самые старые не обработанные). В варианте 2 писатель не должен двигать 

read_index. Сам читатель должен увидеть, что у него read_index обогнан со стороны write_index и промотать сколько нужно. Если read_index будет двигаться из двух потоков одновременно, то никакой атомик уже не поможет: допустим читатель прочитал read_index, начал читать данные, а тут неожиданно ему read_index двигают и данные перетирают -- фигня полная. Тогда полноценный мьютекс нужен. Конечно, можно скопировать данные и ещё раз проверить, что read_index не сдвинулся за это время. Но он же в результате сдвига может 10 раз прокрутиться вокруг всего буфера и остановиться на этом же месте! Поэтому я и говорил про счётчик. По пункту 4 -- зачастую есть заблуждения..., практически такой случай встречается редко (чтоб передача с гарантированной скоростью, и приём тоже с гарантированной и меньшей скоростью). Тот же логгер например -- в него может навалить сколько угодно, без всяких лимитов.

[ZX]