Тормоза при работе с потоком. API. CreateThread.

← →
Zilog (2003-04-18 15:47) [0]

В осоновном модуле, допустим Unit1 создаю отдельный поток с помощью API CreateThread(..). Вся беда в том, что я не могу добиться нормальной работы одновременно и потока и основного модуля программы. Менял приоритет:
THREAD_PRIORITY_IDLE
THREAD_PRIORITY_LOWEST
THREAD_PRIORITY_BELOW_NORMAL
READ_PRIORITY_NORMAL
THREAD_PRIORITY_ABOVE_NORMAL
и т.д. - не помогает. Тормоза смещаются либо в ту, либо в другную сторону.
Подскажите pls как устранить эту проблему?

← →
REA (2003-04-18 15:49) [1]

Телепатией не владеем. Давай куски кода (предварительно упрости программу до 5 строк, которые все тормозят).
А чем TThread не устраивает?

← →
Smithson (2003-04-18 15:59) [2]

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

← →
Zilog (2003-04-18 16:02) [3]

:) Кусок кода, в потоке, отвечает за работу GSM модема: соединение, передача данных, завершение связи.
Насколько я понял - тормозит сам поток, даже если он пуст, просто висит и работает в цикле ничего не делая... С помощью приоритетов я добивался того, что основной модуль не тормозит, но вот поток начинает работать заметно медленней...

TThread - а какая разница? В итоге дельфи то всё равно API юзают...

← →
Zilog (2003-04-18 16:06) [4]

← →
Digitman (2003-04-18 16:09) [5]

> Zilog

давай, давай) ... рассуждай дальше) ...

нет бы код поточной ф-ции привести !

← →
Zilog (2003-04-18 16:13) [6]

Вот, вот эта процедура работает в потоке.

procedure TManager.TransactionAll;
var i : integer; ptr : pointer;
begin
Modem.ViewCmdLog(false);
Modem.SetDelay(250,100);
if not Modem.NetworkRegistration("хххх") then exit;
if Form1.ListView1.Items.Count = 0 then exit;
while Manager.AutoRefresh = true do begin
for i := 0 to Form1.ListView1.Items.Count-1 do begin
ptr := Form1.ListView1.Items.Item[i].Data;
if not Modem.Dial(TStation(ptr).Param.Phone) then break;
WaveList.Items.Items[0].Play(true);
GetRemoteData(ptr);
Modem.Drop;
if not Manager.AutoRefresh then exit;
if i <> Form1.ListView1.Items.Count then begin
Sleep(Options.SpinEdit1.Value*1000);
end;
end;
if Manager.AutoRefresh then begin
Sleep(Options.SpinEdit1.Value*1000);
end;
end;

end;

← →
MBo (2003-04-18 16:15) [7]

настораживает обращение к контролам главной формы, причем многократное

← →
Smithson (2003-04-18 16:16) [8]

Хех!... А загрузка проца почти никакая... Может его всётаки както можно поднапрячь на мои задачи?? а?
Тогда объясни, в чем проблема. Что ты понимаешь под словами "тормозит"?

← →
Digitman (2003-04-18 16:24) [9]

более того - есть подозрение, что вызов метода синхронизирован с осн.код.потоком ! а иначе - как это в принципе может работать нормально, если происходит обращение к VCL-объектам ? тому же ListView, поточно-небезопасному ?

это - раз

второе. а sleep() ? тоже "тормоз" ! при любом раскладе !

← →
Zilog (2003-04-18 16:31) [10]

1) Постораюсь переделать так, чтобы не было обращения к главной форме
2) Тормозит: у меня на главной форме графика, анимация. Вот она начинает лагать, не сильно, но очень не приятно, если я запускаю поток.
3) Подскажите pls. Что значит "вызов метода синхронизирован с осн. кодовым потоком"?
4) Sleep - дык это же нужный %) тормоз. А как мне иначе сделать паузу ничего не делая?

← →
REA (2003-04-18 16:41) [11]

>sleep() ? тоже "тормоз" ! при любом раскладе !

Это какой стороны посмотреть - время отдается процессору и остальным приложениям. Как раз если поток ничего полезного не делает, то надо его периодически в Sleep (или там ReadFile какой) вгонять дабы время не жрал.

← →
Digitman (2003-04-18 16:54) [12]

1) вот с этого и начни

2) в подавляющем большинстве случаев доп.код.потоку нечего соваться в виз.контролы, которыми заведует осн.код.поток ...

осн.задача доп.код.потока - длительные, "тяжелые" вычисления , желательно (и как правило) организованные циклически, дабы иметь возможность оперативно реагировать на адресованные ему сообщения/события

осн.задача осн.код.потока - интерфейс пользователя, своевременная обработка событий осн.устр-в ввода-вывода (клава, мышь, в/контроллер и т.п.)

3) см. 2) ... потоки, работающие параллельно, не должны "мешать друг-другу", обращаясь при этом каждый когда ему вздумается к ресурсам, созданным или занятым другим код.потоком для
"монопольного" контроля ... иначе - полный бардак ! "лебедь, рак и щука" !

4)что значит "нужный" ? зачем тебе пауза ? объясни !

если уж "паузы" нужны, то их следует (по кр.мере - оч желательно) реализовывать иначе - с использованием системных таймеров, ибо в момент блокировки потока на sleep() он не реагирует ни на что !

← →
Zilog (2003-04-18 16:54) [13]

Вот ещё один кусок кода. Тоже запускается отдельным потоком. Обращение к VCL минимальны. Тормозит так же %)

ptr := Form1.ListView1.Selected.Data;

Modem.ViewCmdLog(false);
Modem.SetDelay(250,100);
if not Modem.NetworkRegistration("....") then exit;
if not Modem.Dial(TStation(ptr).Param.Phone) then exit;
WaveList.Items.Items[0].Play(true);
GetRemoteData(ptr);

while ManualMode do begin
if UpdateStation then begin
SetRemoteData(ptr);
GetRemoteData(ptr);
UpdateStation := false;
end;
if ManualRefresh then begin
GetRemoteData(ptr);
ManualRefresh := false;
end;
end;

Modem.Drop;

Что на это скажете, господа мастера? :)

← →
Zilog (2003-04-18 16:57) [14]

Sleep - мне нуж для того, чтобы здалть паузу, например, между набором номера. Допустим идёт дозвон по списку, делаю слипами паузу между каждым набором номера, плюс паузу после обработки всего списка (если список короткий - такое может понадобиться).

← →
Digitman (2003-04-18 17:00) [15]

> REA © (18.04.03 16:41)
> >sleep() ? тоже "тормоз" ! при любом раскладе !
>
> Это какой стороны посмотреть - время отдается процессору
> и остальным приложениям. Как раз если поток ничего полезного
> не делает, то надо его периодически в Sleep (или там ReadFile
> какой) вгонять дабы время не жрал.

ну и отдай "время" вызовом любой ф-ции ожидания ! например. того же таймера !
зачем потоку бесцельно время терять ? он же слеп и гух в момент sleep() ! а вызовом ф-ции ожидания событий/сообщений "убиваются сразу 2 зайца" !

← →
MBo (2003-04-18 17:02) [16]

Ты бы все-таки почитал чего-нибудь...

← →
Digitman (2003-04-18 17:04) [17]

> Zilog

а если в момент sleep() необходимо срочно завершить работу код.потока ? а код.поток, отработав такую паузу, начнет как ни в чем ни бывало новый набор номера ? как тогда ? ты думал об этом в принципе ?

← →
Zilog (2003-04-18 17:09) [18]

Да у меня там после слипа проверка boolean"a стоит. Всё в порядке, выход работает на ура :)). Лучше подскажи почему тормозит!... %))))))

MBo!... :)))) Обязательно!... Уже сейчас парралельно читаю! Но в этом случае то у меня вроде как всё боле-менн правильно ведь...

Sleep"ы не мешают основному потоку, выход корректный... обращения к VCL минимальны, а точнее - единожды происходит....

← →
Zilog (2003-04-18 17:13) [19]

Во втором случае, ксти и слипов нет. А тормоза отсаются... ПолтерГейтс?

← →
Digitman (2003-04-18 17:19) [20]

> Zilog

> Sleep"ы не мешают основному потоку, выход корректный

да что ты говоришь ?) юзер нажал кнопулю "Зарыть приложение" - и будеть ждать-париться, пока твой поток 20-секундный слип отработает ?? да на черта ему, юзеру, такая прога нужна ! он ее скорей снимет за такую "провинность" через менеджер задач).. почем юзеру знать, "зависла" прога или "спит" по твоей неразумной логике ?

> обращения к VCL минимальны, а точнее - единожды происходит....

этого досточно для "глюка" в самый неожиданный для тебя момент)

← →
Zilog (2003-04-18 17:22) [21]

Ладно, как это отношение имеет в данный момент к торможению потока? Хрен с ним, переделаю я этот слип в какой нибудь таймер, однократное обращение к VCL тож уберу. Только я уверен что это от сабжа не избавит....

← →
Digitman (2003-04-18 17:30) [22]

> Zilog

мы тут так и не поняли по сей момент - в чем, по-твоему, "тормоз" проявляется ? ты в состоянии хотя бы "на огурцах" описать ?) долго тебя пытать ?)

и - приведи наконец-то ПОЛНЫЙ код поточной ф-ции !

← →
Zilog (2003-04-18 17:33) [23]

Максимум на что могу грешить - дык это на работу с модемом через компорт...

← →
Digitman (2003-04-18 17:40) [24]

> Zilog

ну и выкинь ее ("работу с модемом через компорт") на время эксперимента по поиску "тормоза" ! подмени ее каким-нибудь эмулятором ! да тем же слипом, в конце-концов, подмени !

оставь вообще в потоке один слип, вызываемый в цикле с булевым условием выхода, и убедись, что работа доп.потока никак не влияет на производительность осн.потока !

← →
Zilog (2003-04-18 17:45) [25]

Вот поток кода на данный момент:
//--------------------------
while ManualMode do begin
Modem.SetDelay(250,100);
end;
//--------------------------

ПОТОК ТОРМОЗИТ всё равно...

Это для информации:
procedure TModem.SetDelay(Transmit, Recive : byte);
begin
TransmitDelay := Transmit;
ReciveDelay := Recive;
end;

← →
Digitman (2003-04-18 17:57) [26]

> Zilog

и что ? ты хочешь сказать, что кроме вот этой циклической фитюльки в теле поточной ф-ции больше ничего нет ???

← →
Zilog (2003-04-18 18:02) [27]

Я только что сделал проще - пустое тело потока. И всё равно тормозит. Вот в чём муля то!!!.... Хех!... Я ж не настолько туп %)))

← →
Zilog (2003-04-21 09:36) [28]

Ну что? Никто не ришит интересную задачку? %)

← →
Digitman (2003-04-21 09:53) [29]

угу... ты будешь еще год тут жеманиться, полный код своей поточной ф-ции скрывать от нас, а мы тут на кофейной гуще гадать будем, как "рИшить" твою "задачку" ?) ... нет уж нет уж !) ... уволь))))

← →
REA (2003-04-21 10:26) [30]

>зачем потоку бесцельно время терять ? он же слеп и гух в момент
>sleep() ! а вызовом ф-ции ожидания событий/сообщений "убиваются
>сразу 2 зайца" !

Согласен. Но в принципе Sleep(1) или Sleep(10) не приводят к существенным тормозам и использовать их при необходимости можно, т.к. оно (кажется) не увеличивает загрузку процессора.

← →
Digitman (2003-04-21 10:40) [31]

> REA

Да кто ж спорит !)
Речь как раз о том и идет, что не слип виноват, а какие-то несуразицы где-то в теле поточной функции, но - ЗА пределами приведенной процедуры ! А автор никак не желает привести полный код, составляющий тело поточной ф-ции)...

← →
ErikIvanov (2003-04-21 13:05) [32]

To Zilog
Да бывает, наверное раньше в КГБ работал? И никому невериш. Хочу тебя огорчить тебе говорить правду TThread действительно работает и нетормозить в сотнях тысяч проектах.

← →
evvcom (2003-04-21 14:44) [33]

Присоединяюсь. Недавно пришлось разобраться с потоками. Написал целый менеджер управления потоками, запускал штук по 10. Все четко работает и ничего не тормозит. Разберись с критическими данными и синхронизацией потоков. Короче почитай Д.Рихтера "Windows для профессионалов", там все довольно понятно описано.

Тормоза при работе с потоком. API. CreateThread. Найти похожие ветки