Kovalenko Dmitry wrote:
Я бы сделал работу следующим образом: поток-читатель считывает из базы
блок данных и передаёт его на обработку второму потоку через
PostThreadMessage (по старинке) или QueueUserAPC (по современному).
Размер блока данных подбирается чтобы его обработка занимала примерно
полсекунды.
Я это сделал через "буфер обмена", защищенным критческой секцией.
Тогда не понятно в чём может быть затык. Ты бы лучше куски кода
постил, а то телепатия нынче редкость.
- Послушал как работает машина (в натуре на слух), и понял - нужно
нафиг отключить буферизацию файловых операций. То бишь указал флаги
FILE_FLAG_WRITE_THROUGH, FILE_FLAG_NO_BUFFERING
Ага. Именно назад, к природе. А ты ещё на IBAPI бочку катил ;)
На самом деле FILE_FLAG_WRITE_THROUGH имеет смысл для увеличения
надёжности и когда памяти в компе мало. Если памяти много, то
этот флаг лучше не ставить. FILE_FLAG_NO_BUFFERING я вообше не
понимаю чем тут может помочь.
отказаться от
мелких блоков, а перейти к блокам занимающим всю страницу целиком.
Продолбенился над реализацией целый день. Получилось красиво.
И - о чудо! У меня многопоточная реализация стала работать вровень с
однопоточной.
Ну что и следовало доказать. При увеличении размера блоков издержки
на синхронизацию в процентном отношении падают.
Напомню, мне нужно построить уникальный индекс для (по последним
прогнозам) 100 лимонов элементов вида (ID1, ID2). Максимум что я смог
осилить - 20 лимонов.
Что значит осилить? Какая цель то?
--
--- Home Page http://ok.novgorod.net/ap ---