stanilarВот такое читал?
Пролистал статью, раньше ее не видел. Странная.
1. Вначале предлагается использование FreeOnTerminate, OnTerminate и Synchronize как панацею от всех бед, при этом не описываются связанные с этим грабли. Хотя статья времен D5, когда Synchronize работал через SendMessage, и граблей было поэтому меньше, но часть их была всё равно.
2. Потом, наконец, честно описываются обычные проблемы, которые возникают из-за использования вышепредложенного мусора, типа дэдлоков при WaitFor и Synchronize/OnTerminate, и героические пути их решения. При чем таким тоном, как будто эти муки - обычная необходимая вещь, рутина в жизни любого опытного программера.
3. И в конце - создание более-менее похожего на жизнеспособный примера без использования всего этого говна, и радостное заключение: "Мы достигли нашей цели!.. Не используется Synchronize. Потоки без необходимости не блокируются"!
Да, неожиданный конец. Вернее, в реальной жизни всегда так - как ни пытайся сделать яичницу из теннисных шариков, всё равно придется сходить в магазин за яйцами.
Но странно, когда статья изначально в споре зеленого и черного топит за зеленое, а заканчивается утверждением, что черное лучше.

Вообще, впечатление, что автор статьи - мазохист.

По теме.
1-й вариант - нормальный. 3 параметра в конструктор потока, например.

white_niggerВообще-то это хрестоматийная книга по потокам в делфи, необходимая каждому, кто хочет научится ими пользоваться
Я в тебе и не сомневался

Док,

Не знаю, я лично не люблю в структурах автоматические типы.

ДокКонечно, хочется сделать какой-нибудь универсальный наследник потока.
Универсальность обычно ухудшает функциональность.
Совсем универсально можно сделать так:


Таким образом Params для передачи в конструктор потока можно создавать перед созданием объекта потока и сразу удалять, а можно вообще объект Params общий держать (или несколько), только некоторые данные в нем менять (если в одном потоке)... И ничего не надо будет синхронизировать никогда (касательно этих Params).

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

stanilarможно синхронизировать датасурс с датасетом после завершения запроса (говоря по другому - передать всю бизнесс-логику в поток)?
Если "передать всю бизнесс-логику в поток" - то зачем тогда "синхронизировать датасурс с датасетом после завершения запроса"?

Или я не понял нифига.

stanilarYuRockзачем тогда "синхронизировать датасурс с датасетом после завершения запроса"

Показать данные на форме надо?Откуда я знаю?
Док в этих темах, вообще-то, занимается именно реализацией бизнес-логики в доп. потоках. Поэтому как-то странно звучит совет "перенести бизнес-логику в доп. поток".

ДокПожалуй, отдам предпочтение наглядности в ущерб универсализму.Очевидно, у каждого своё представление о наглядности)

stanilarПочему тогда поток данных(цитата: "передаете параметры запроса в поток") направлен в поток а не из потока?Потому, что эти параметры нужны потоку перед началом работы, а не после?

stanilarДокПоясни

Если бизнес-логика в потоке, то синхронизировать надо не передачу параметров в поток, а отображение полученных в потоке данных.Синхронизировать надо и то, и другое. Если есть.

stanilarYuRockпараметры нужны потоку перед началом работы

Параметры запросов не часть бизнес-логики клиента БД?В том-то и дело. Но вводятся-то они в другом потоке по любому.

Дока смысл? Те же n-цать запросов я могу и на клиенте в одну процедуру затолкать...Ну, смысл большой.
Сервер откомпилирует ее как одно целое один раз заранее. А не будет компилировать n-цать запросов каждый раз.
Плюс не будет накладных расходов на кучу сетевых запросов.
Будет намного быстрее.
Если запросы быстрые (как и должно быть) - может быстрее в разы, а то и на порядки (зависит от n, сети, скорости компиляции и выполнения запросов, размера базы...).