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 ---


Ответить