Потоки, приоритеты и подобное

[Sergey2]

Пишу программу. Она собирает данные с устройтсва и обрабатывает их. Ньюанс в том, что данные идут потоком и их надо считывать постоянно, если где-то "тормознуть", то данные пропадут. В связи с этим съем данных было выделенно в отдельный поток, который пишет данные в пямять, а основная программа их потом обрабатывает.
Пробелмма в том, что это нифига не помогло, т.е. Все равно при больших вычислениях данные теряются. Почему отдельный поток торомзит? Приоритет выставлен максимальный. Выглядит код примерно так:

Thread:=TD.Create(false);
Thread.FreeOnTerminate:=true;
Thread.Priority:=tpTimeCritical;


while (not (pBuf=pBuf^.DefHook)) do 
  begin
    CalcData; 
    ProgressBar2.Position:=Bcount; {показ индикатора работы}
  end;

Дело в том что обработка идет в одной функции? В нее понапихать Application.ProcessMessage? Или тоже в отдельый поток выносить?

[B_N]

А что это за такое странное устройство, к которому у Вас есть, видимо, прямой доступ под Windows, но, судя по всему, нет драйвера??? Windows не гарантирует точную синхронизацию и тем более непрерывную работу потока. Скорее наоборот - гарантирует, что Ваш поток будет постоянно прерываться - это основа работы любой многозадачной ОС на ограниченом числе процессоров.

[Sergey2]

Сообщение от B_N

А что это за такое странное устройство, к которому у Вас есть, видимо, прямой доступ под Windows, но, судя по всему, нет драйвера???

Есть драйвер. Устройство конектится по usb и начинает слать данные. Если из буфера их вовремя не забрать, то они заменяютмся на новые. Но вопрос не про это.

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

Т.е. вариант один - основной программе вытсавлять минимальный приоритет и молиться богу что винды не отнимут много времени у потока, который забирает данные? Имеет ли смысл впихивать в функцию обсчета Application.ProcessMessage? Или вынос ее отдельный поток?

[B_N]

Sergey2, если есть драйвер, значит он должен справляться с этой проблемой самомтоятельно с помощью своего буфера. К тому же все устройства уже очень-очень давно работают через прерывания и такая ископаемая схема с непрерывным опросом порта практически не использовалась уже в восьмидесятые. Отсюда и мой вопрос - странно это как-то. Может быть стоит разобраться с драйвером? Или с устройством? Как это так, оно шлёт данные, которые у него не просит драйвер, судя по тому, что у него не выбран буфер. Что касается приоритетов - это абсолютно ничего не даст (если я всё-таки правильно понял проблему). Запустите System Monitor и посмотрите, сколько происходит переключений контекста в секунду и сколько в системе работает потоков, даже не учитывая, что есть сугубо "ядерные" потоки. Сразу сможете примерно прикинуть сколько времени и с какими промежутками работает Ваш поток. Насчёт Application.ProcessMessage не совсем понял. Это вообще никакого отношения к потокам не имеет, по крайней мере применительно к этой проблеме.

[Sergey2]

Сообщение от B_N

Sergey2, если есть драйвер, значит он должен справляться с этой проблемой самомтоятельно с помощью своего буфера. К тому же все устройства уже очень-очень давно работают через прерывания и такая ископаемая схема с непрерывным опросом порта практически не использовалась уже в восьмидесятые. Отсюда и мой вопрос - странно это как-то. Может быть стоит разобраться с драйвером? Или с устройством? Как это так, оно шлёт данные, которые у него не просит драйвер, судя по тому, что у него не выбран буфер.

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

Что касается приоритетов - это абсолютно ничего не даст (если я всё-таки правильно понял проблему). Запустите System Monitor и посмотрите, сколько происходит переключений контекста в секунду и сколько в системе работает потоков, даже не учитывая, что есть сугубо "ядерные" потоки. Сразу сможете примерно прикинуть сколько времени и с какими промежутками работает Ваш поток. Насчёт Application.ProcessMessage не совсем понял. Это вообще никакого отношения к потокам не имеет, по крайней мере применительно к этой проблеме.

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

[Stilet]

По-моему было бы не лишним мануал по устройству и драйверу почитать...

[alexBlack]

Сообщение от Sergey2

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

Из примера не видно, как Вы делаете выборку данных из буфера и как сообщаете о том, что буфер выбран. По-моему дело в синхронизации.

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

Нет, не ждет. Это опять приводит нас к синхронизации.

[B_N]

Сообщение от Sergey2

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

Sergey2, Вы движетесь не в том направлении. Играть с приоритетами и пытаться "успеть" за буфером, значит получить программу, которая будет работать (и не работать) по-разному не только на разным машинах и версиях ОС, но даже в пределах одного своего запуска. Раз особой информации о девайсе Вы не сообщили, приходится только гадать - может Вам поможет Overlapped IO, может написание своего драйвера к этому устройству, может просто размещение своего кода в ядре и т.д., а может просто буфер побольше или файл-мэппинг. Тем более, что в том виде, как Вы описываете, устройство (или драйвер) работает, по всей видимости, неправильно.

Сообщение от Sergey2

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

Поток, вызвавший функцию, ждёт возврата из неё, и то с несколькими уточнениями. Системе же, другим процессам и даже другим потокам Вашего процесса сей вызов абсолютно безразличен. Application.ProcessMessage это просто стандартная комбинация из GetMessage - TranslateMessage - DispatchMessage.

[Sergey2]

Устройтсво не может "ждать". Оно льет и льет. Дело не в драйверах. По другому никак. И другого устройства не будет.

[B_N]

Сообщение от Sergey2

Устройтсво не может "ждать". Оно льет и льет. Дело не в драйверах. По другому никак. И другого устройства не будет.

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