Да не нужна мне твоя схема. Нужен а л г о р и т м. хотя бы в таком виде:
1. Данные для программы берём из Com-порта в формате ХХХХХХХХХ на скорости ХХХХХХ ????
2. Записываю их в БД (расшифровка почему, зачем и нахрена)
3. вот здесь поподробней - почему так происходит ? Или запрос задаешь неверный, или не знаешь оператор GROUP BY, который выдаст один результат даже из миллиона одинаковых.
и т.д.
А схема твоя совершенно не нужна.
Вот когда распишешь свой алгоритм, тогда может и сам поймешь где глючит.
ну отвечай ты по человечески - какие строки ? короткие ? километровые ?
Какие поля в таблице БД ? Какие поля проверяешь и по каким критериям ?

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

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

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

Я дал схему не стека, а ОЧЕРЕДИ, это разные вещи. Если тебе нужен чистый стек, то зачем ты лепишь сторонний компонент StackEx

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

Вот именно, через один, а не через семь разномастных, работающих каждый в своем потоке
К тому же, .dbf тогда и SQLite сейчас -- несколько разные вещи
Да и не только это послужило вынесению записи в отдельный модуль, а ее постоянное наращивание занимаемой памяти. Кстати, такой же болезнью страдает MSSQL, за месяц вырастает до 1,5 Гб

nesco, стек - первый вошел-последний вышел, а этот стек - наоборот.
Ну а алгоритм не дам - набрал все, а форум его унес в 500 эррор. Кнопка "назад" показала девственный лист. Нервы сдали и решил что разбираться буду сам на основе последних советов .
------------ Дoбавленo в 17.25:
nesco, опишите, пожалуйста как именно делали разделение? Просто в фоновом приложении или обычной форме? Как-то разделяли приоритеты процессора? Запускали фоновую после запуска основной? Какие-то тонкости есть?

Невидимая форма, обязательно нужно окно для отработки очереди.

Зачем, система сама распределяет нагрузку процессоров

Основная сама запускает writer, если он не запущен, а иначе -- коннектится по UDP к уже запущенной

а мне и не надо - это тебе надо

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

Редактировалось 1 раз(а), последний 2017-03-04 01:31:29

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

Что и требовалось доказать Семь страниц ушло на то, чтобы выявить проблему в элементах, которых даже не было на схемах с описанием проблемы.

1nd1g0, и я всё время просил "огласить весь список" (общий алгоритм)

да и ты тоже


Neo, а теперь убери и стек и потоки и будет успевать работать


------------ Дoбавленo в 08.34:
А если выложишь алгоритм проги, то и вес уменьим до 200 кб и БД успевать будет и читать и писать и считать.