Дегтярев ЕвгенийMolochnikСмысл этого простой - очередь. Каждый поток по очереди выбирает первую доступную запись для обработки и помечает ее как используемую. Если потоки будут читать одновременно они могут выбрать одну и туже запись.

сделайте один поток, ответственный за распределение заданий из очереди

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

Опять вернулся к этой задаче и к вашему методу решения. Интересно что у меня примерно так раньше (лет 10 назад) так и работало, когда один поток лазил в базу и создавал очередь заданий в памяти (кэш), к которой уже обращались потоки обработчики, не лазящие в базу. Потом я бросил этот способ, поскольку:
1) кэш иногда переполнялся, если ни одному потоку не нужна была запись долгое время (а может и не вовсе не пригодилась бы),
2) приходилось отслеживать его актуальность, если таблица менялась сторонней программой,
3) иногда нужной записи не было в кэше и поток простаивал.
Все это конечно решалось, но выглядело сложно и уродливо, и я бросил этот способ в пользу теперешней схемы. Если рассматривать вариант без кэша, когда данные берутся из таблицы только когда они реально нужны (онлайн), то в чем тогда преимущество одного потока перед несколькими потоками, работающими через критическую секцию? В оверхеде работы критической секции? Это разве не "ловля блох"? Хотя потоков может быть и штук двести.

Дегтярев Евгений,
Жаль в форуме нет кнопки "проблема решена", а то можно было бы нажать.
Все сделал как здесь вы и другие советовали:
1) В базу лазит только один поток (супервизор), он регулярно создает небольшую очередь (ThreadList) для чтения для каждого из типов потоков-обработчиков и еще одну - для записи в базу. Типов потоков-обработчиков обычно мало (как правило один). Кэш при любых изменениях базы из сторонней программы очищается.
2) Потоки обработчики работают: берут Item из одной очереди, обрабатывают его и кладут в другую. Поток-супервизор регулярно обновляет базу записывая все изменения в одной транзакции и очищая очередь записи.
3) Аккуратно сгладил все потенциальные затыки и сейчас уже при 10ти потоках этот механизм работает намного веселее а при 200х - вообще небо и земля
4) Также изначально с FB была проблема, что выборка по условию осуществлялась долго, если поле условия (приоритет) находится в отдельной таблице и везде одинаково (В MS SQL этой проблемы не было). Поэтому сделал дополнительное поле в основной таблице выборки, куда и дублирую значение приоритета. Все стало работать идеально: со скоростью сравнимой с MS SQL (всего раза в 2-3 медленннее, а не на 3 порядка на 50 тыс записей).

Troglodit,
там реально было две проблемы.
1) Первая, медленно запрос делался. Сейчас есть свободное время, сделал тесты, урезал базу и запрос до минимума. Вот что получилось:
Сама заполненная база - ссылка (ссылка неделю хранится)

Медленный запрос:


Быстрый запрос по "лишнему полю" Priority, которое оказалось совсем нелишним и с помощью которого я обошел проблему (здесь посоветовали):



2) Вторая, много потоков, каждый из которых лазил в базу на чтение и на запись. Работало на небольшом числе потоков, но очень плохо масштабировалось. Если потоков становилось несколько десятков уже довольно сильно тормозило, а если их сотня система вообще становилась неработоспособной. Эту я решил сделав один поток работающим с базой, а остальные потоки работающими с очередями запросов.

Вложенный файл таблицы стилей это я просто тесты с форумом проводил - не мог поверить что 150 кб это максимум (архив базы у меня 500 занимает). Причем удалить сылку уже нельзя как я понял.

во втором запросе, вы явно не используете contacts, пытаетесь запутать оптимизатор?
2. Что именно тормозит можете по человечески объяснить.
2.1 Это вашe приложение на delphi? может проще воспользоваться готовыми проверенными очередями, которые работают без проблем? По моей памяти с мультитредом в делфи все очень плохо. Вы давно слышали фразу "Гляди какой классный http-сервер, наверно он написан на Delphi"?
2.2 СУБД? крайне странно с учетом малого количества потоков. В мое время птица спокойно держала десятки коннектов в рабочем порядке на железе 15 летней давности. Думаю текущая версия еще лучше.
Ответы
1. Почему не использую? Contacts не используется в тестовом примере, а вообще используется, причем много полей
2. Просто можете проверить выполнение запроса в IBExpert, первый ("медленный") выполняется на этой базе у меня около 200 мс, а второй ("быстрый") - мгновенно. Причем с увеличением числа записей скорость "меленного" падает в геметрической прогрессии. Причем:
а) в запросе нет условий и берется всего одна запись (по логике первая попавшаяся) и запрос по идее не должен тормозить
б) значение поля приоритета везде одинаковое, но индекс по нему в ActiveTaskContacts очень важен и без него "быстрый" запрос выполняется также медленно. Где то на форуме давно читал что в firebird/interbase по маломеняющемуся полю индексы смысла нет строить. Этот же пример говорит об обратном - индекс точно нужен даже для неменяющегося поля.
в) в то же время индекс по полю приоритета в таблице Contacts не влияет на скорость
г) в MS SQL скорость выполнения обоих запросов одинаково быстрая и независимая от наличия индексов (быстрее "быстрого" запроса в Firebird раза в три), т.е. именно так и должно быть по логике запроса (достань первую попавшуюся запись)
2.1 Здесь все нормально, в Дельфях сейчас все хорошо и с потоками и параллелелизмом, сам пользуюсь TThread, TThreadList и TParallel когда по смыслу надо. С TThreadedQueue у меня не заладилось, возможностей мало, проще здесь свое было сделать. Сейчас тестировал на ноутбуке 400 потоковую систему, тормозов нет вообще, все идеально работает.
2.2 сейчас использую FB 3.0. Коннекты держит, не падает, это точно, но даже визуально (у меня работа потоков визуализирована) видно что схема с одним потоком "базы" работает на порядок быстрее уже при 10 потоках-обработчиках. При схеме с одним потоком в базу много запросов выполняется в одной траназкции и это сильно ускоряет дело.

kdv,
Да, имел ввиду поле с малым разнообразием значений, в данном случае их максимальное количество 5 но обычно используется одно

б) Это поле (Priority) имеет не мало, а "одно" значение. Индексу может и плохо но запросу хорошо.
в) Участвует, в запросе это видно невооруженным взглядом
г) fb настройки оптимизированные, ms sql все по умолчанию
2.1 Исходные коды всех дельфийских реализаций присуствуют, там очень быстрый спуск на нижний уровень WinApi, чтото там новое делать это ловить блох
2.2 Да раньше каждый поток создавал полностью независимое соединение по которому соединялся с БД в начале своей работы и отключался в конце. А потоки работали все время работы программы. Так что можно конечно такую реализацию и пулом назвать просто "пулом постоянных соединений". В другом месте у меня переменное число потоков (обработка сетевых запросов) разного времени жизни, там как раз нормальный пул: коннекты по мере надобности создаются и живут своей жизнью. Изредка происходит очистка.
Обрабатываеть в одной транзакции данные от разных потоков согласен в общем случае может и не совсем верно. Но в данном случае все хорошо - запросы же одни и же просто с разными параметрами. Если теоретически один запрос завалит всю транзакцию (реально это невозможно) ничего страшного, в следующий раз пройдет.
"Умные дядьки" уже придумали вместо критических секций использовать TMonitor, который вроде как быстрее, я туда и не лезу, может и правда быстрее, надежность точно не ниже.

Я уже говорил, сейчас все работает близко к идеалу и поэтому вопрос организации монгопоточности меня не так сильно волнует - на ноуте у меня 400 потоков работало почти не напрягая проц.

Да, значение в поле только одно, по нему сортировка и индекс очень даже нужен оказывается.
Так чего говорить то? база есть - скачать, зарегистрировать в айбиэксперте и выполнить указанные запросы, потом удалить индекс и опять выполнить. У меня часто бывает что клиент видит сразу то чего не вижу я, может и здесь так же