Вверх ↑
Этот топик читают: Гость
Ответов: 704
Рейтинг: 7
#1: 2011-08-18 22:39:12 ЛС | профиль | цитата
Подскажите, почему после добавления вот этого блочка программа после пару часов-десятка часов зависает мертво, хотя до этого работала месяцами без выключения. И убрать не могу - без него уже туго, и кусается больно Памяти на момент выделено висяка как обычно. Процессорное использование 0%. Винда предлагает слать отчет. Может я, без осознаия того, использую какой компонент, который долго работать не умеет?
code_24946.txt


------------ Дoбавленo в 22.39:
Как уже поднимал раньше, суть блочка - накопление и поочередная выдача событий дабы избежать накладок данных.
карма: 0

0
файлы: 1code_24946.txt [1.4KB] [210]
Гость
Ответов: 17029
Рейтинг: 0
#2: 2011-08-18 22:49:14 правка | ЛС | профиль | цитата


Редактировалось 2 раз(а), последний 2025-01-09 07:12:23
карма: 0

0
Ответов: 1536
Рейтинг: 176
#3: 2011-08-18 23:07:09 ЛС | профиль | цитата
Neo, я как-то тоже когда-то столкнулся с проблемой потоков. Заменил все MMTimer простым Timer и проблема исчезла. Кроме того, ты используешь сторонний компонент. Попробуй всёже собрать на стандартных компонентах. Ссылку на сторонний компонент не помешало бы.
карма: 1
Не так страшна ошибка, как опасность её не заметить.

0
Разработчик
Ответов: 26170
Рейтинг: 2127
#4: 2011-08-18 23:10:04 ЛС | профиль | цитата
Neo, мне кажется, что неправильно расставлены критические секции, и зачем там вообще MMTimer
------------ Дoбавленo в 23.10:
О! И у ser_davkin-a появлялась такая же ситуация, и он сделал замену мультимедийного таймера обычным. Что, в принципе, я и имел в виду, и тогда там совершенно не нужны будут критические секции в этом месте
карма: 22

0
Ответов: 1536
Рейтинг: 176
#5: 2011-08-18 23:11:50 ЛС | профиль | цитата
[flood]
nesco писал(а):
О! И у ser_davkin-a появлялась такая же ситуация
Опыт, сын ошибок трудных...[/flood]
карма: 1
Не так страшна ошибка, как опасность её не заметить.

0
Ответов: 704
Рейтинг: 7
#6: 2011-08-18 23:35:33 ЛС | профиль | цитата
Выпорол себя розгой по пальцам (забыл про сторонний компонент). Но там стоял стек с возможностью обратки LIFO. Проверен он годом добротной работы и на него грешить не могу.
Переставил туда стандартный стек (то же самое, просто не пользую его).

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

Критические секции нужны чтоб не получилось что идет запись и одновременно чтение из стека.

code_24947.txt
карма: 0

0
файлы: 1code_24947.txt [1.3KB] [186]
Ответов: 3889
Рейтинг: 362
#7: 2011-08-18 23:40:47 ЛС | профиль | цитата
Neo, SafeMode к doPop настройте на noWait. И что-то намудрено всё, я же давал пример гораздо проще и делающий то же самое.
карма: 1

0
Разработчик
Ответов: 26170
Рейтинг: 2127
#8: 2011-08-19 00:06:18 ЛС | профиль | цитата
Neo писал(а):
Критические секции нужны чтоб не получилось что идет запись и одновременно чтение из стека

На обычном таймере такого не будет
карма: 22

0
Ответов: 704
Рейтинг: 7
#9: 2011-08-19 00:15:33 ЛС | профиль | цитата
1nd1g0, но вы же писали что они должны быть с одинаковым значением wait.
------------ Дoбавленo в 00.15:
1nd1g0, вот Ваша схема, но после стека событие не уходит новым потоком. После стека же оно уже в общем потоке, или я ошибаюсь?

Add(MultiElement,9607509,329,161)
{
@Hint=#29:Новый поток с теми же данными|
@Color=0
}
BEGIN_SDK
Add(EditMulti,15066390,35,21)
{
EventCount=1
WorkCount=2
Height=137
link(doWork1,12551667:doSafeMode,[(73,27)(73,55)])
link(doWork2,2883:doStart,[(53,34)(53,62)])
}
Add(Thread,2883,63,56)
{
@Hint=#20:Запуск нового потока|
link(onExec,10410781:doSafeMode,[])
}
Add(SafeMode,12551667,112,49)
{
WaitMode=1
link(onSafeMode,12717953:doPush,[])
}
Add(SafeMode,10410781,168,56)
{
WaitMode=1
link(onSafeMode,12717953:doPop,[])
}
Add(Stack,12717953,259,49)
{
Default=String(Пусто)
IgnorEmpty=1
link(onPop,15066390:onEvent1,[(313,62)(313,27)])
}
END_SDK


------------ Дoбавленo в 00.15:
И у себя я дожидаюсь завершения этого потока.
карма: 0

0
Ответов: 3889
Рейтинг: 362
#10: 2011-08-19 00:23:25 ЛС | профиль | цитата
Neo, Wait нужен только на запись, о чём я собственно, и писал.

Neo писал(а):
После стека же оно уже в общем потоке, или я ошибаюсь?

Ошибаетесь, новый поток начинается с onTimer (MMTimer )и кончается только на doStart (Thread), где вы из потока запускаете ещё один поток. Не удивительно что, наплодив замороженных потоков, схема зависает
карма: 1

1
Голосовали:Neo
Ответов: 704
Рейтинг: 7
#11: 2011-08-19 01:21:29 ЛС | профиль | цитата
1nd1g0, подскажите, а можно как-то мониторить, что поток с данными со стека завершился, если я переделываю так? В Вашей схеме thread выплевывает со стека постоянно данные, которые не успеют выполнится и произойдет такая же накладка, от которой я бежал.
code_24948.txt
------------ Дoбавленo в 01.20:
Одни данные у меня пролетают за 50 миллисекунд, а другие могут до 1,5 секунды обрабатываться. При этом не после каждой обработки данных есть событие...
------------ Дoбавленo в 01.21:
Тогда я четко видел когда поток еще выполняется, а сейчас новая проблема
карма: 0

0
файлы: 1code_24948.txt [866B] [207]
Ответов: 3889
Рейтинг: 362
#12: 2011-08-19 08:55:37 ЛС | профиль | цитата
Neo писал(а):
как-то мониторить, что поток с данными со стека завершился, если я переделываю так?

Обычно - не за зачем, SafeMode с noWait после onExec гарантированно прервёт исполнение кода после onSafeMode столько раз, сколько понадобится для отработки параллельного потока, запущенного с парного SafeMode.

Но если очень долго может отрабатывать поток, и параллельный поток очень активно кладёт на стек, тогда либо ставить Wait, либо порождать очередной поток, для надёжности можно его останавливать (только не из самого себя, а через Timer, например).
------------ Дoбавленo в 08.41:
Neo писал(а):
произойдет такая же накладка, от которой я бежал

С noWait вообще ничего не произойдёт, ветка после onSafeMode просто не будет выполняться, если же она начала исполняться, то отработает полностью. Но Вы обязаны помнить, что вся она принадлежит отдельному потоку, у Вас могут быть конфликты с параллельными потоками там, где не используетсяне возможно использовать SafeMode. Это уже забота программиста - отслеживать такие ньюансы.

Именно по-этому Вам тут рекомендуют использовать обычный Timer или точку onSyncExec (Thread) (точность хуже MMTimer, зато интервал срабатывания много меньше 16 мсек, характерных для Timer)- по сути, это псевдомногопоточное программирование, зато практически исключены конфликты за одни и те же данные, не надо ломать голову над "непонятными глюками" типа тех, с которыми Вы сталкиваетесь.
------------ Дoбавленo в 08.55:
Neo писал(а):
а сейчас новая проблема

За Вас всё "видит" SafeMode (WaitMode=NoWait):


Add(MultiElement,4063234,532,63)
{
@Hint=#29:Новый поток с теми же данными|
@Color=0
}
BEGIN_SDK
Add(EditMulti,15066390,21,21)
{
EventCount=1
WorkCount=1
Width=237
Height=193
link(doWork1,13267528:doSafeMode,[(45,27)(45,62)])
}
Add(MMTimer,16297399,77,147)
{
Interval=30
link(onTimer,10907756:doSafeMode,[])
}
Add(SafeMode,13267528,126,56)
{
Name="My_SafeMode3"
link(onSafeMode,14867656:doPush,[(180,62)(180,104)])
}
Add(SafeMode,10907756,126,147)
{
Name="My_SafeMode3"
WaitMode=1
link(onSafeMode,14867656:doPop,[(180,153)(180,111)])
}
Add(Stack,14867656,203,98)
{
link(onPop,15066390:onEvent1,[(239,111)(239,27)])
}
END_SDK

карма: 1

0
Разработчик
Ответов: 26170
Рейтинг: 2127
#13: 2011-08-19 08:55:42 ЛС | профиль | цитата
1nd1g0 писал(а):
только не из самого себя, а через Timer, например

И из самого себя можно. Самый классический случай останова, это останов из синхронного метода, те, через точку onSyncExec, в этом случае, таймер совершенно не нужен
карма: 22

0
Ответов: 3889
Рейтинг: 362
#14: 2011-08-19 09:22:08 ЛС | профиль | цитата
nesco, [режим телепата] Судя по его схемам и постам, ему был нужен именно независимый поток, способный 1,5 секунды работать на отдельном ядрепроцессоре параллельно со своими клонами на других ядрах или что там у него ещё программа делает. В этом контексте я и писал.[/режим телепата] Про синхронное исполнение тоже писал, ещё в прошлых топиках, если память не изменяет, но он выбирает асинхронные варианты.
карма: 1

0
Разработчик
Ответов: 26170
Рейтинг: 2127
#15: 2011-08-19 10:21:54 ЛС | профиль | цитата
1nd1g0 писал(а):
Судя по его схемам и постам, ему был нужен именно независимый поток, способный 1,5 секунды работать на отдельном ядрепроцессоре параллельно со своими клонами на других ядрах или что там у него ещё программа делает

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

0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)