Потоки команд

← →
Adm (2008-01-18 17:51) [0]

Подскажите, плз, как сделать!
Есть модуль потока команд. В теле программы (в основном потоке) я хочу запустить 3 потока (с разными параметрами на входе), чтоб они работали параллельно. Как это реализовать?

← →
Kolan © (2008-01-18 17:53) [1]

3 раза создай объект потока и все.

← →
Leonid Troyanovsky © (2008-01-18 19:52) [2]

> Adm (18.01.08 17:51)

> Есть модуль потока команд.

Потрудитесь излагать ваши мысли яснее.

--
Regards, LVT.

← →
Palladin © (2008-01-18 21:59) [3]

ну видимо модуль is юнит, поток is class(TThread)

← →
Германн © (2008-01-19 00:34) [4]

> Palladin © (18.01.08 21:59) [3]
>
> ну видимо модуль is юнит, поток is class(TThread)
>

Два термина объяснил. А третий? Что есть команда?
:)

← →
Palladin © (2008-01-19 12:28) [5]

ну видимо безсвязный набор вызовов процедур функций и методов в перемешку с присвоениями переменным каких либо значений, который по идее должен выполнять какую то полезную работу - комманда

← →
Сергей М. © (2008-01-19 12:39) [6]

> хочу запустить 3 потока (с разными параметрами на входе),
> чтоб они работали параллельно. Как это реализовать?

BeginThread(...параметр1 ..)
BeginThread(...параметр2 ..)
BeginThread(...параметр3 ..)

← →
TStas © (2008-01-19 16:41) [7]

Не забывая, что если из потоков, происходит обращение к чему-то, что вызовет перерисовку на экране, то делать надо это через Syncronize. Что потоки очень противно отлаживать, т. к. нужно организовать отладочный вывод из потока и простой отладчик в этом плохой помощник. Что часто, если такая возможность есть, работу, которая потом будет выполнена в потоке, отладить в отдельном модуле, а затем запускать в виде потока (Thread). А еще, что очень часто, даже почти везде, без потоков с их мучительной отладкой можно обойтись, заменив их работу в главном потоке, с вызовом Application.ProgressMessages, не злоупотребляя частотой вызовов, т. к. из-за этого тормозит.
Если Вы поясните, зачем Вам их сразу три потребовалось, может, что еще подскажу.

← →
MetalFan © (2008-01-20 01:29) [8]

> Не забывая, что если из потоков, происходит обращение к
> чему-то, что вызовет перерисовку на экране, то делать надо
> это через Syncronize.

чушь. в Synchronize необходимо оборачивать обращение к объектам VCL главного потока программы.

> т. к. нужно организовать отладочный вывод из потока и простой
> отладчик в этом плохой помощник.

всегда отлаживал многопоточные приложения делфей. проблем серьезных не наблюдал.

> еще, что очень часто, даже почти везде, без потоков с их
> мучительной отладкой можно обойтись, заменив их работу в
> главном потоке, с вызовом Application.ProgressMessages,
> не злоупотребляя частотой вызовов, т. к. из-за этого тормозит.

о да! потоки - зло!
а может ты не умеешь их готовить?!

> MetalFan © (20.01.08 01:29) [8]
>
>

С третьим тезисом TStas © (19.01.08 16:41) [7] я лично соглашусь. Но с поправкой. Дело не столько в отладке, сколько с ненужностью доп. потоков в каком-то конкретном случае (Бритва Оккама) и не умении решить задачу иначе.

> Не забывая, что если из потоков, происходит обращение к
> чему-то, что вызовет перерисовку на экране, то делать надо
> это через Syncronize.

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

> Что потоки очень противно отлаживать, т. к. нужно организовать
> отладочный вывод из потока и простой отладчик в этом плохой
> помощник.

Потоки противно отлаживать (и отладчик виснет) в основном, когда существуют прорехи в организации синхронизации с основным потоком (например, вызов ShowMessage() из дополнительного потока почти гарантированно приводит с зависанию отладчика). В иных случаях проблем с отладкой потоков практически не наблюдается.

> А еще, что очень часто, даже почти везде, без потоков с
> их мучительной отладкой можно обойтись, заменив их работу
> в главном потоке, с вызовом Application.ProgressMessages,
> не злоупотребляя частотой вызовов, т. к. из-за этого тормозит.

Если задача действительно настолько проста, что для ее решения достаточно обойтись Application.ProgressMessages, то причем тут потоки? Необходимость использования дополнительных потоков нужно оценивать адекватно, исходя из задачи. Там, где они действительно нужны, заменить их Application.ProgressMessages невозможно! :)

> я хочу запустить 3 потока

Может именно в это дело? Тогда [7] + [9]. "И главное - не перепутать!"(с)

Опаньки! "м" в этом не пропечаталась... :(

Потоки команд Найти похожие ветки