Kovalenko Dmitry wrote:
Смотря какая природа у этого варианта. У меня сейчас два потока
работают
- один грузит данные из базы
- второй эти данные обрабатывает.
В идеале первый поток не нужен. Например, если коннектится к серверу
через асинхронный сокет, то достаточно обрабатывать сообщения о
поступлении новых данных. Т.е. в событии OnRead сокета запрашиваем
фетч следующей порции данных, обрабатываем полученную и ждём
новых сообщений. Но, при работе с gds32.dll такое невозможно.
Я бы сделал работу следующим образом: поток-читатель считывает из базы
блок данных и передаёт его на обработку второму потоку через
PostThreadMessage (по старинке) или QueueUserAPC (по современному).
Размер блока данных подбирается чтобы его обработка занимала примерно
полсекунды.
У этих потоков одна точка соприкосновения - буфер обмена, в которых
каждый проводит не очень много времени.
Дело не во времени, а сколько раз в секунду происходит обращение
к объектам синхронизации типа мьютеков. Даже если мьютекс свободен
это достаточно дорого.
проблема в том, что первый успевает насытить буфер с исходными данными
под завязку, а второй пашет как ненормальный что бы этот буфер
освободить, но очень редко когда его опустошает.
А проблема то в чем? Конечно, при любых алгоритмах нужно приостанавливать
фетч если данные обрабатываются медленно.
И ещё, получается что у тебя обработка данных занимает времени намного
больше чем их выкачка из базы. В такой ситуации выигрышь от
распараллеливания невелик в процентом отношении.
--
--- Home Page http://ok.novgorod.net/ap ---
