Как опрашивать датчик очень быстро и успевать писать данные в файл ?

Получится ли решить проблему, если сброс на диск делать в низкоприоритетном потоке ?

Не знаю точно про винду, но на линуксе это можно делать в потоке с любым приоритетом - если он заблочится на I/O, активны будут только те потоки, которым есть чего делать

что за датчик, чем подсоединён, в качестве стореджа именно жёсткий диск, который с блинами и крутится? На чём это вообще всё запущено? Что мешает сохранять чаще? Какой размер буфера?

классическая двух буферная схема. пишешь в один, сбрасываешь другой. при переполнении отдаешь текущий на сброс, а пишешь в уже сброшенный. просто меняешь указатели на буфера и все

int Buf1[1000],Buf2[1000];

int *current = &Buf1;
int *for_save = &Buf2;

Пишешь в current, как только переполнился - обмениваешь значения current и for_save, и запускаешь сброс for_save на диск.

условие - сброс должен быть быстрее чем заполнение пустого буфера. ну и должно быть два треда - один датчик читает, другой сбрасывает буфер

Почему бы не просто писать в файл и не позволить ядру в фоне сбрасывать данные на диск?

Linux тут при чем? Или у тебя откомпиленный через borland c++ код под вайном запускается и опрашивает датчик? Про MSVC тут тоже так спрашивать можно теперь?

Датчик по usb опрашивают, снимают большие массивы данных с него, крутится все на убогом компе с pentium и 2 гиг оперативы у заказчика. Размер буфера максимально большой, чтобы реже писать на диск.

Сброс как раз скорей всего будет больше по длительности, можете подсказать схему как реализовать этот вариант кроме способа набить десяток буферов)

Отладка идет на нормальных компах у нас, а у заказчика оффтопик со слабыми компами, жалуются на потери данных.

а зачем писать на диск реже, когда можно писать чаще

какой поток данных с датчика и какая пропускная способность у диска? Если второе меньше, то все усилия тщетны :)

Linux тут при чем?

Ну линакс же бисплатен. Значит на форуме по линакс бисплатно помогут разобраться с задачей.

какой поток данных с датчика и какая пропускная способность у диска? Если второе меньше, то все усилия тщетны

Существует ещё зжатие

Это никак не показывает связи с Linux

По теме - делаешь два буфера, когда один из них забивается данными, сразу перескакиваешь на заполнение другого буфера и пинаешь другой специальный тред, который пусть только что заполненный буфер в файл записывает. IPC механизмы в винде точно какие-то есть, можно через мьютекс тупо. В винде вот какие-то критические секции есть https://docs.microsoft.com/en-us/windows/win32/sync/using-critical-section-ob...

Ну или можно семафор, в винапи он тоже есть

Borland C++ в 2020 году?

Датчик по usb опрашивают, снимают большие массивы данных с него, крутится все на убогом компе с pentium и 2 гиг оперативы у заказчика. Размер буфера максимально большой, чтобы реже писать на диск.

говори какой размер буфера, за сколько он забивается данными, как часто происходит сброс на диск. если диск в принципе не поспевает за данными,… то ты его весь запишешь минут за 10. сколько ж там данных-то?

если данных больше чем он успевает писать, ты вообще проблему не решишь.

вариант кроме способа набить десяток буферов

Не блокирующий кольцевой буфер, два треда. Один пишет в буфер данные с датчика по кругу, второй оттуда сбрасывает данные на диск, по мере возможности.

Не блокирующий кольцевой буфер, два треда. Один пишет в буфер данные с датчика по кругу, второй оттуда сбрасывает данные на диск, по мере возможности.

сбрасывать надо блоками поскольку диск любит блочную запись. а о готовности блока знает принимающий данные тред. вот он формирует блок и сигналит записывающему треду, что надо блок писать. а с кольцевым буфером записывающий тред будет будиться по каждому байту в кольцевом буфере, и опять засыпать, поскольку должен ждать когда блок с данными будет сформирован.

будет будиться по каждому байту в кольцевом буфере

это с какой же радости?

сигналит записывающему треду, что надо блок писать

С какой радости №2? Он что, зная, что данные поступают в буфер с определенной скоростью не может прикинуть время, сколько ему еще поспать, если он проснулся, а блок не готов?

сигналит записывающему треду

ну то есть с какой радости вообще кто-то кому-то о чем-то будет сигналить?

вы еще спросите - а с какой радости тред?

Я думаю ТС ещё и зарабатывает раз в 15 больше чем все отписавшиеся в треде. На дельфи точно ребята в провинции пишут за те деньги, которые олимпиадникам из яндекса даже и не снились.

Нужно писать в кольцевой страничный буфер в шаренной памяти между двумя процессами. Один процесс наполняет начало кольца, другой - пишет страничками с конца.

В линуксе многие сисколы для процесса используют общую блокировку, т.е. не могут работать одновременно. Если с устрйства читаешь сисколом, что вероятно, то даже если разнесёшь чтение и запись по потокам, то чтения по-прежнему будут просаживаться на записи.

Или же писать через aio или io_uring

Нужно писать в кольцевой страничный буфер в шаренной памяти между двумя процессами. Один процесс наполняет начало кольца, другой - пишет страничками с конца.

очнитесь товарищ. процессы используются для изоляции приложений друг от друга. а ему просто надо чтобы одно действо не блокировало другое, в его приложении. для этого существуют треды. причем с процессами все будет только хуже чем с тредами. ..совсем с ума посходили…

ты ему еще посоветуй еще через гигабит эзернет прокидывать буфер от одного процесса к другому. хехе.

чтобы скинуть на диск. хехе.

один процесс!!! читает датчик, другой процесс!!! на диск пишет. может ему сразу кластер поставить и сисадмина нанять?

Выкинуть всё нахрен включая с++ setbuff(stdout,NULL); и писать в цикле обычным сразу данные как только они опрошены обычными fprintf()/write().

буфер memory mapped на файл и когда наполняется, прога делает сброс на диск.

В том может и проблема, копите гиг и скидываете его. Ясен пень будет блокировка и просранные тайминги.

Ты прикинь, а у нас на работе именно многопроцессное приложение работает уже много лет. Один процесс опрашивает датчики (отдельный процесс на каждый тип датчика) и пишет в общую память, другой процесс пересылает эти значения по сети на другие компы, третий - анализирует значения и логи пишет, четвертый - пишет в БД. Вообщем приложение запускает около 30 процессов. И работа любого процесса независит от работы остальных и каждый процесс можно независимо перезапустить (например, поменяв конфиг-файл). Плюс еще каждый управляющий комп имеет горячий резерв.

Ты прикинь, а у нас на работе именно многопроцессное приложение работает уже много лет. Один процесс опрашивает датчики (отдельный процесс на каждый тип датчика) и пишет в общую память, другой процесс пересылает эти значения по сети на другие компы, третий - анализирует значения и логи пишет, четвертый - пишет в БД

давай оставаться в рамках конкретной сиутации. у клиента какой-то пыльный комп, что ему достался от бабушки. и всего-то задача - читать данные и бросать на диск. и основная проблема, что комп слабый.

а ты рассказываешь ситуацию, когда у вас целый кластер, сеть, бд и все такое. и проблем с аппаратурой нет.

получится. но в маздае с таймерами всё плохо, убедитесь, что вы не используете sleep.

И как можно исправить эту проблему видимо с хардом ?

[*]SSD?
[*]tmpfs?

Проге лет 10, тогда borland был видимо популярен, а сейчас заказчик заметил проблемы, поэтому приходится на borland править код.

Я имел ввиду программные пути, крутой комп заказчики не дадут.

Программные пути уже подсказали. Два буфера. Пока один записывается, второй скидывается на жесткий диск другим тредом. Или тебе надо чтобы тебе готовый код написали? В чем вопрос вообще?

Мне нужно, чтобы когда 2 поток будет скидывать данные на диск, его выполнение прерывалось 1-ым потоком для опроса датчика. Как это сделать ? Достаточно выставить 2-ому потоку низкий приоритет ? Не будет ли 1 поток в моменты сброса просаживать ? Также интересен вариант 2 процесса и разделяемая память. Можете пояснить про этот вариант, почему он будет хуже или лучше.

Мне нужно, чтобы когда 2 поток будет скидывать данные на диск, его выполнение прерывалось 1-ым потоком для опроса датчика.

тз то какое? датчик пассивный, то есть ты его опращиваешь, или активный - сам кидает данные и ты должен реагировать.

если пассивный то правильно так:

обычно опрос делают по таймеру, то есть таймер будет пробуждать поток1, поток1 будет брать данные и класть в буфер. затем поток1 проверяет, полон ли буфер, и если да - переставляет указатели буферов, сигналит потоку2 о готовности данных, и засыпает(его пробудит таймер). но поток должен гарантировано отработать быстрей чем частота таймера, иначе можно пропустить следующий тик таймера.

поток2 ждет на условной переменной или любом обьекте синхронизации, что имеет функцию wait(таймаут(про таймаут отдельный разговор)). поток1 говорит этой условной переменной(когда буфер полон) - разбудить ожидающего, то есть поток2.

поток2 будится и начинает сброс данных. как только сброс данных закончен, поток2 опять встает на ожидание на эту условную переменную(на которой поток1 опять скажет ему - данные готовы, сбрасывай).

зачем потоку2 таймаут на ожидании? потому что если поток1 остановить, то поток 2 будет ждать данных бесконечно. вот чтобы это не происходило, поток2 встает на большой таймаут(гарантировано больше чем периоды его пробуждения потоком1), например если поток1 пробуждает поток2 раз в секунду, то таймаут например 10 секунд. то есть если поток2 сошел с ожидания по таймауту - это ситуация обрабатывается как факт, что поток1 застрял или умер. тут можно или завершать поток2, или давать на консоль диагностику - «поток1 не проявляет активности!!!»

даже при равных приоритетах это будет работать, поскольку ос будет потоки быстро переключать. поскольку у тебя частота опроса датчика 3 мс, проблемы быть не должно, потому что шедулер треды все равно быстрей переключит. но если чтение датчика будет пропускаться, можно понизить приоритет треда2.

это минимальная и правильная кухня, которая будет работать всегда, кроме случая, что у тебя обьем данных в секунду от датчика, превышает пропускную способность диска на запись. тогда вообще ничто не спасает. или бери меньше данных, или ставь более быстрый диск.

Мне нужно, чтобы когда 2 поток будет скидывать данные на диск, его выполнение прерывалось 1-ым потоком для опроса датчика.

Чего? Сам-то подумай, если у тебя так много данных с датчика идет, то поток 2 просто будет постоянно заблокирован в такой схеме. Это раз.

Два, по-хорошему чтение с одного девайса и запись в другой девайс разных участков памяти должны нормально распараллеливаться, и блокирования никакого тебе не понадобится. Не морочь людям головы, сделай ты эти несчастные два буфера, и будет тебе счастье.

Еще один хинт: если ты пишешь на диск, а не в tmpfs какую-нибудь, то тебе лучше писать не часто и по несколько байтов, а редко и большими порциями.

можете подсказать схему как реализовать этот вариант кроме способа набить десяток буферов

Диски взять SSD, писать на несколько дисков с чередованием

Диски взять SSD

Бюджетная организация, не дадут)

датчик пассивный

Да, опрашивается с компа по запросу в цикле.

Бюджетная организация, не дадут)

ты на вопрос ответь уже - поток данных у тебя какой с датчика. в мегабайтах в секунду. и какой диск стоит у клиента(пусть в системных свойствах посмотрят). вот выше чем пропускная способность этого диска, и даже в районе ее(он разная для разного положения головки) ты данные не спасешь. а если данных в секунду раз в 10 меньше, чем у пропускная способность диска, то запросто.

Да, опрашивается с компа по запросу в цикле.

цикл просто молотит, или на таймере, или со слипом?

два диска можно поставить. Даже если денег не дадут, снять с соседней такой же дохлой машины. Это удвоит пропускную способность на запись

Молотит, наполняет буфер и делает сброс, эта схема успешно работает, сброс выполняется за 1 мс, но иногда какие-то просаживания идут и сброс на 100 мс занимает. У нас эмуляторы железа, у заказчика реал оборудование. Проблемы на реал оборудовании идут.

Даже если денег не дадут, снять с соседней такой же дохлой машины.

Там все серьезно, пломбы и прочее у заказчика)

Ну тебе уже посоветовали читать одним ядром, писать другим ядром, данные между ними протаскивать через общую память. Что ты ещё хочешь услышать?

Двухядерные пентиумы бывают: https://en.wikipedia.org/wiki/Pentium#Pentium_Dual-Core_2

читать одним ядром, писать другим ядром

А вот это интереснее, на машине core 2 duo стоит. Мне нужно в коде что-то указывать или ось сама распихает 2 треда по ядрам. Типа можно ли именно распараллелить эти 2 потока на ядра, чтобы они исполнялись одновременно ?

Молотит, наполняет буфер и делает сброс, эта схема успешно работает, сброс выполняется за 1 мс, но иногда какие-то просаживания идут и сброс на 100 мс занимает. У нас эмуляторы железа, у заказчика реал оборудование. Проблемы на реал оборудовании идут.

1. зачем молотит? установите в ТЗ фиксированную частоту приема данных, устраивающую заказчика. чем реже, тем лучше. когда молотит - значит вы пытаетесь читать данные максимально часто, но для этого должна быть цель.

2. сколько ядер на компе клиента

3. что за диск на компе клиента.

4. ОПЯТЬ! сколько байт данных считывается в секунду?

сколько ядер на компе клиента

про ядра уже понял. 2 ядра. ось сама распихает треды на два ядра, если не тупая.

опять же надо понимать, что если на целевой машине еще что-то крутится и время ест, это будет мешать вашему приложению и вашим тредам.

ось сама распихает треды на два ядра, если не тупая.

Можно гвоздями прибить, чтобы наверняка.
https://en.wikipedia.org/wiki/Processor_affinity

On Linux, the CPU affinity of a process can be altered with the taskset(1) program[2] and the sched_setaffinity(2) system call. The affinity of a thread can be altered with one of the library functions: pthread_setaffinity_np(3) or pthread_attr_setaffinity_np(3).