помогите с разобраться с потоками

← →
KSergey © (2005-01-10 11:11) [40]

> Zahar (09.01.05 15:31)
> Есть текстовый файл в котором N-строк с числами (для примера
> возьмем 300).

Хотелось бы по исходной задаче немного написать.
Если это просто учебная проба - то ладно.
А вообще имейте в виду, что один поток (например - основной) в итоге обработает вась файл быстрее, нежели N параллельных, обрабатывающих разные куски файла.

← →
Alexander Panov © (2005-01-10 11:14) [41]

KSergey © (10.01.05 11:11) [40]
А вообще имейте в виду, что один поток (например - основной) в итоге обработает вась файл быстрее, нежели N параллельных, обрабатывающих разные куски файла.

Если система однопроцессорная. Но и при этом условии тоже не факт. Зависит от того, какая обработка данных проводится , от контроллра дисков, от объема RAM и пр...

← →
TUser © (2005-01-10 11:29) [42]

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

← →
KSergey © (2005-01-10 12:57) [43]

> [41] Alexander Panov © (10.01.05 11:14)
> KSergey © (10.01.05 11:11) [40]
> Если система однопроцессорная. Но и при этом условии тоже
> не факт.

ПРи каком "этом"? При многопроцессорности или однопроцессорности?

← →
sniknik © (2005-01-10 14:37) [44]

> ПРи каком "этом"? При многопроцессорности или однопроцессорности?
так понимаю смотря что "тормозит", если расчеты то вряд ли разнесение по потокам даст прирост скорости...
но вот если поток в основном занимается ожиданием события какого нибудь то несколько вполне мугут сработать быстрее (пример FlashGet при закачке в несколько потоков). и неважно сколько процессоров. ;)

← →
sniknik © (2005-01-10 14:47) [45]

olookin © (10.01.05 10:30) [39]
> " имелось в виду НАЗНАЧЕНИЕ свойства, а не его чтение.

чтение тоже "чревато" последствиями, ты читаеш другой поток пишет в итоке ты получил неопределенное значение, часть от старого часть нового значения. это хорошо?
ну и потом даже чтение свойства (property) может вызывать довольно сложные процедуры (и на запись тоже) смотря как оно реализовано, а если (например) гдето подсчет вхождений в свойство идет и выход только с парным (вход + выход -, и выйдет только если 0), ты туда влез незапланировано... и в итоге "клинч" ни ты ни основной поток работать не можете, зависли в обработке проперти. (только как пример!)

[45] sniknik © (10.01.05 14:47)

Согласен, но в отношении моего кода - могу я беспрепятственно читать "имя" компонента, или это тоже чревато?

olookin © (10.01.05 15:30) [46]
нельзя! ни в коем случае (даже если на первый взгяд кажется что можно, и не с чем не пересекается не изменяется и .т.д.)
всегда есть вероятность (и очень очень большая) что гдето чтото не учел, мало ли событий в которых туда же обращение и блокировки ставятся. (onPaint например, ты учитывал? в нем тоже должно быть обращение к компонентам формы) а если вдруг исключение будет? там по ексепту VCL-ная форма с мессажем подымается, в потоке это недопустимо.

помогите с разобраться с потоками Найти похожие ветки