![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
TThread - Хм....Виснет однако....
Pepe © (2011-06-19 12:15:00)Добрый времени суток, уважаемые гуру. Столкнулся с проблемой потоков. Ранее особо этой областью не пользовался. Но сейчас этого требуют обстоятельства. Задача передо мной такая. Открывать одновременно несколько файлов и считывать из них достаточно большой объём информации.
Но.... эта система крошится даже при работе всего одного потока. Главный поток зависает, т.е форма и прочие элементы интерфейса перестают быть юзабельными до тех пор пока не завершится работа того потока который работает с файлом. Приведу краткое содержание моего потока, возможно я что-то упустил и это вызывает негодование у программы.
type
TNTPTurnLoading = class(TThread)
private
CalcItem: Pointer;
protected
procedure Execute; override;
procedure DoWork;
public
constructor Create(P: PItem); virtual;
destructor Destroy; override;
end;
procedure TNTPTurnLoading.DoWork;
var
NA: TMyClass;
begin
NA:= TMyClass.Create;
NA.FileName:= PItem(CalcItem)^.FileName;
if Na.ReadData>-1 then
begin
PItem(CalcItem)^.Data1:= na.Data1;
PItem(CalcItem)^.Data2:= na.Data2;
end;
pl.UpdateIndex(CalcItem);
Na.Free;
end;
constructor TNTPTurnLoading.Create(P: PItem);
begin
CalcItem:= p;
inherited Create(False);
end;
procedure TNTPTurnLoading.Execute;
begin
if CalcItem = nil then Terminate;
Synchronize(DoWord);
Terminate;
Создаётся такой поток посредством
TNTPTurnLoading.Create(Pointer);
Надеюсь вы мне поможете разобраться в сложившихся обстоятельствах.
Ega23 (2011-06-21 19:49:00) [1]
> Хм... спасибо за новодку, действительно я видать не так
> понял документацию по потокам.
Дело покойного Архангельского живёт и процветает.
Уже который год.
tesseract (2011-06-21 18:02:00) [2]
> Более вероятно, что скорость будет ниже, чем при последовательном
> чтении.
Зависеть будет и от сложности алгоритма обработки / число процессоров. Ну и отложенное чтение сильно снимает нагрузку.
>
> if Na.ReadData>-1 then
> begin
> PItem(CalcItem)^.Data1:= na.Data1;
> PItem(CalcItem)^.Data2:= na.Data2;
> end;
> pl.UpdateIndex(CalcItem);
А откуда взялся pl ?
Да и держи в помощь : http://sourceforge.net/projects/threadpoolpas/
antonn (work) (2011-06-20 12:30:00) [3]более того, если вдруг понадобиться читать файл из сети (\\192.168.1.2\c$\file.txt) то перед самим чтением будет неслабый подзависон
Pepe (2011-06-20 08:42:00) [4]
> Вы совершенно правы. Довольно приличный объём данных считывается
> в память и потом смещением +1 за цикл обрабатываются. Последовательная
> обработка в таком случае очень не эффективно смотрится.
> Это занимает долгое время, если идти методом очередей.
Pepe (2011-06-20 08:41:00) [5]
> Может данные долго обрабатываются по ходу считывания.
Вы совершенно правы. Довольно приличный объём данных считывается в память и потом смещением +1 за цикл обрабатываются. Последовательность в таком случае очень не эффективно смотрится. Это занимает долгое время, если идти метод очередей.
Inovet (2011-06-19 16:17:00) [6]> [4] Loginov Dmitry © (19.06.11 15:02)
> Для чего их открывать и считывать одновременно?
Может данные долго обрабатываются по ходу считывания.
Loginov Dmitry (2011-06-19 15:02:00) [7]
> Открывать одновременно несколько файлов и считывать из них
> достаточно большой объём информации.
Для чего их открывать и считывать одновременно? Думаешь, что одновременная работа окажется быстрее последовательной? Оно да, если имеется несколько подключенных к компьютеру винчестеров, и на каждом - по файлу. Но в рамках одного винчестера параллелизма все равно не добъешься (если конечно файлы не закешируются операционной системой или жестким диском). Более вероятно, что скорость будет ниже, чем при последовательном чтении.
Юрий Зотов (2011-06-19 13:04:00) [8]if CalcItem = nil then Terminate;
Наверное, здесь надо Exit, а не Terminate.
Pepe (2011-06-19 12:43:00) [9]
> Даже не вдаваясь в изучение подробностей, что ты там делаешь,
> видно, что вся работа у тебя выполняется не во вторичном,
> а фактически в основном потоке приложения (см. Synchronize(DoWord);
> )
Хм... спасибо за новодку, действительно я видать не так понял документацию по потокам.
Применив Syncronize только к pl.UpdateIndex(CalcItem);
А остальное отправив в Execute зависания пропали, как буд-то их и не было.
Спасибо большое =) Великолепные люди здесь сидят однако, который вопрос уже задаю. Хоть и наводками но.... так даже интереснее искать суть своей проблемы.
DVM (2011-06-19 12:37:00) [10]
> Pepe (19.06.11 12:15)
> Главный поток зависает, т.е форма и прочие элементы интерфейса
> перестают быть юзабельными до тех пор пока не завершится
> работа того потока который работает с файлом.
Даже не вдаваясь в изучение подробностей, что ты там делаешь, видно, что вся работа у тебя выполняется не во вторичном, а фактически в основном потоке приложения (см. Synchronize(DoWord);)