Есть ли NOOP?
| Автор |
Повідомлення |
|
Повідомлення створено: 22. 06. 2011 [11:06]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"almaz" wrote:
Сделал бы, если бы знал все подводные течения в скаде на Вашем уровне. Незнаючи можно одно сделать, а другое поломать. Речь же о коррекции уже сделанного, да и то на уровне обсуждения. Если даже не корректировать - хотя бы знать будем.
Раз не можете тогда и молчите и не предлагайте глупости. Когда я Вам предлагаю это сделать лично я имею ввиду, что начав лично разбираться Вы поймете что это или очень сложно, вплоть до полного нарушения работоспособности, или просто не реально.
"almaz" wrote:
Подвисания свидетельствуют о некорректном разделении данных между процессами. Другой вывод при зависании всего конфигуратора из-за ява-программы не напрашивается. Ява-программа захватывает доступ к общим данным на всё время исполнения, хотя данные ей нужны только на короткие времена (чтение на входе, запись на выходе, вызовы из ява-программы других участков кода и др.).
Глупость. Читаем исходный код.
"almaz" wrote:
Даже если конфигуратор не подвешивать, всё равно галочками длительную ява-программу не остановить...
Делайте.
"almaz" wrote:
А ведь длительными могут стать и вроде бы недолгие ява-программы. Например, при обрыве связи и отработке таймаутов (время исполнения превышает период запуска), при случайной ошибке в ява-программе (бесконечный цикл) и др. Всё это может приводить к зависаниям всей скады, а не только некоторого участка проекта, уже при эксплуатации на реальном объекте.
Поэтому и не нужно ставить бессмысленно больших таймаутов и поэтому есть лимиты. Зацикливание не приводит к зависанию и для этого есть лимит вычисления функций JavaLikeCalc, и если вы его накрутили то это тоже Ваша проблема.
Если знаете как прервать поток не уронив процесса и не залочив навсегда ресурсы целиком то сделайте принудительное прерывание, а не рассказывайте тут.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 22. 06. 2011 [12:24]
|
|
almaz
Almaz Karimov
Contributor
Зареєстрован(а) с: 25.09.2008
Повідомлення: 516
|
Лимит времени, установленный для ява-программы, не срабатывает. sleep 5 секунд, лимит 1 секунда, время исполнения контроллера показывает 5 секунд 6-9 миллисекунд.
Принудительное прерывание потока некорректно. Поток должен завершиться сам по команде извне. Похоже потоки не отслеживают ни состояние своих галочек, ни лимит времени.
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Повідомлення створено: 22. 06. 2011 [12:48]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"almaz" wrote:
Лимит времени, установленный для ява-программы, не срабатывает. sleep 5 секунд, лимит 1 секунда, время исполнения контроллера показывает 5 секунд 6-9 миллисекунд.
Срабатывает, однако там есть особенность. Читаем исходник.
"almaz" wrote:
Принудительное прерывание потока некорректно. Поток должен завершиться сам по команде извне. Похоже потоки не отслеживают ни состояние своих галочек, ни лимит времени.
Поток не может быть прерван принудительно в принципе. Читаем теорию уже в конце концов!
Потоку может быть отослан сигнал, например, SIGALRM для прерывания функций вроде sleep. Прервать sleep системного вызова таким образом нельзя.
Поэтому добавил SYS.sleep() и расширил функцию удаления потока повтором отправки SIGALRM в течении ожидания завершения потока.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 23. 06. 2011 [12:49]
|
|
almaz
Almaz Karimov
Contributor
Зареєстрован(а) с: 25.09.2008
Повідомлення: 516
|
Принудительно поток может быть прерван посредством pthread_cancel. Прерываемый поток при этом может устанавливать разрешения (когда его можно прервать, когда - нет) посредством pthread_setcancelstate и pthread_setcanceltype. Это нужно для корректной работы с общими ресурсами. Кроме того, прерываемый поток может подчистить за собой при принудительном завершении занятую память. Теория:
http://www.regatta.cmc.msu.ru/doc/usr/share/man/info/ru_RU/a_doc_lib/aixprggd/genprogc/term_threads.htm#HDRD3A4499232MANU
Просматривая исходники возник другой вопрос: каким образом потоки OpenSCADA разделяют общие ресурсы? Не могу никак найти... Вроде как с помощью условных переменных и на ВЕСЬ активный период работы потока (процедур Task)... Что может приводить к торможениям не только интерфейса, но и при обмене данными между модулями... Захват ресурса одним потоком должен происходить на минимально возможный срок (только чтобы выполнить необходимую операцию с ресурсом; выполнение чтения-записи памяти обычно занимает малое время).
http://www.regatta.cmc.msu.ru/doc/usr/share/man/info/ru_RU/a_doc_lib/aixprggd/genprogc/sync_over.htm#HDRSYNCH_OVERBMORT
[Повідомлення редагувалось 4 раз(ів), останній раз 23.06.2011 в 13:16.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Повідомлення створено: 23. 06. 2011 [13:45]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
Правильно, только pthread_cancel это уже не принудительно. И попробуйте теперь представить как Вы будете везде расставлять pthread_setcancelstate, насколько велика будет вероятность зависание именно в этом участке, насколько в результате распухнет код и насколько это всё станет ещё более нестабильно.
В общем, сначала читаем код, затем тестируем реальность, а уже затем талкаем глубокомысленные речи.
"almaz" wrote:
Просматривая исходники возник другой вопрос: каким образом потоки OpenSCADA разделяют общие ресурсы? Не могу никак найти... Вроде как с помощью условных переменных и на ВЕСЬ активный период работы потока (процедур Task)...
С какого потолка такие предположения?
Все ресурсы определены здесь: src/resalloc.h
"almaz" wrote:
Что может приводить к торможениям не только интерфейса, но и при обмене данными между модулями...
У меня ничего не тормозит.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 23. 06. 2011 [14:34]
|
|
almaz
Almaz Karimov
Contributor
Зареєстрован(а) с: 25.09.2008
Повідомлення: 516
|
По крайней мере, pthread_cancel прервёт поток на любом участке кода, не взятом в "скобки" из pthread_setcancelstate. Независимо от того, системный sleep это или затянувшаяся ява-программа пользователя, не ведущая в данный момент чтение-запись ресурсов.
У Вас программа не тормозит, потому что формируете проект так, чтобы не тормозило. Попробуйте запустить несколько контроллеров с ява-циклом for(var j=0; j < 5000000; j++); (примерно 5 сек) или со sleep(5) и ещё с передачей вычисляемых переменных между модулями, например с периодом 100 мсек. Программа в принципе не должна притормаживать, если процессор свободен. Тем более и с внешними устройствами обмена нет (хотя это тоже не может быть причиной торможения интерфейса)...
Понимаю, что расставлять такие "скобки" из pthread_setcancelstate по всей скаде непросто. Зависаний и нестабильности при точной их установке быть не должно. Распухания кода при введении новых строк действительно не избежать, но оно же оправдано.
Эти "скобки", как бы уже должны быть, только в виде других команд, которые никак не найду в коде... Чтобы убедиться, что захват ресурсов потоками происходит на минимально возможный срок. На мысль, что захват происходит посредством переменных, навела инверсия переменных is_start, is-stop в циклах процедур Task. И как же происходит захват-разблокировка ресурсов в процедурах Task? На какой промежуток времени происходит один захват в рабочем цикле?
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Повідомлення створено: 23. 06. 2011 [15:02]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"almaz" wrote:
По крайней мере, pthread_cancel прервёт поток на любом участке кода, не взятом в "скобки" из pthread_setcancelstate. Независимо от того, системный sleep это или затянувшаяся ява-программа пользователя, не ведущая в данный момент чтение-запись ресурсов.
И всё рухнет! Нельзя же так откровенно демонстрировать свою "компетентность". Наверное я уже прекращу отвечать на Ваши глупости, пока вы подтверждать свои слова делом не начнёте.
"almaz" wrote:
У Вас программа не тормозит, потому что формируете проект так, чтобы не тормозило.
И это правильно! Если Вы бездумно ерунду создаёте то кто Вам доктор? Знаете нож замечательный инструмент в умелых руках, а вот дурак им и зарежется, может ножи запретим? Я же думаю, что ножи лучше дуракам не давать.
"almaz" wrote:
Понимаю, что расставлять такие "скобки" из pthread_setcancelstate по всей скаде непросто. Зависаний и нестабильности при точной их установке быть не должно. Распухания кода при введении новых строк действительно не избежать, но оно же оправдано.
Ничего Вы не понимаете. Начните делать тогда, воможно, поймёте.
"almaz" wrote:
И как же происходит захват-разблокировка ресурсов в процедурах Task? На какой промежуток времени происходит один захват в рабочем цикле?
Читаем код, там всё исчерпывающе написано.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 24. 06. 2011 [02:20]
|
|
almaz
Almaz Karimov
Contributor
Зареєстрован(а) с: 25.09.2008
Повідомлення: 516
|
Конечно всё рухнет, если не выполнять при прерывании потока завершающие процедуры (закрытие файлов, портов, освобождение заблокированных ресурсов, динамически распределённой памяти, деструкторы). Для этого есть функции pthread_cleanup_push и pthread_cleanup_pop, о которых нет упоминаний в Вашем справочнике http://wiki.oscada.org/RomanSavochenko/CShortAll
http://lib.ololo.cc/b/149177/read#t129
Чтобы подтвердить делом нужно знать все критичные места в исходном коде. Чего о себе сказать не могу, поэтому продолжу изучать исходный код.
Проект с длительными процедурами (ерунду) создавал не бездумно, а целенаправленно, чтобы засечь "узкие" места в программе. Право на жизнь длительных алгоритмов показано в начале темы. Метод тестирования такой, заметьте, с соблюдением всех правил формирования проекта скады и ява-программ. Есть метод ещё эффективнее - внесение неисправностей, то есть нарушение всего что позволяет нарушить программа.
Аналогия с инструментом немного некорректна. Речь скорее о заточке инструмента, чем о дураках или запретах.
Чтобы перестали отвечать мне абсолютно ни к чему. Поэтому больше не буду заострять внимание на данном вопросе. Остановимся на том, что это трудоёмко и требует особого внимания при написании исходного кода в дальнейшем. Тем более надо понимать, что при зарождении OpenSCADA с функциями pthread_* были неопределённости в POSIX, из-за чего эти функции в старых ядрах и операционных системах работали непредсказуемо (неодинаково), что очень влияло на переносимость кода. В современных ядрах и ОС, вроде как, уже всё налажено.
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Повідомлення створено: 24. 06. 2011 [08:06]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
То что их там нет ещё не говорит о том, что я о них не знаю.
Хоть суть проблемы ресурсов до Вас дошла. Ещё осталось осмыслить факт неформализуемости задачи для корректного освобождения ресурсов и прийдём к выводу, что прерывать нельзя или можно, но только в крайне узком диапазоне мест где ресурсы можно формализовать, но по сути, окажется, что зацикливания там никогда не будет.
"almaz" wrote:
Проект с длительными процедурами (ерунду) создавал не бездумно, а целенаправленно, чтобы засечь "узкие" места в программе. Право на жизнь длительных алгоритмов показано в начале темы.
Смотря где. В потоке визуализации проекта любые действия несвязанные с визуализацией в принципе не должны иметь место. Тем более sleep() и это не предмет дискуссии, если же очень хочется то сходите в QT4 и расскажите им про это.
В других местах у меня нет проблем с продолжительными задачами.
"almaz" wrote:
Аналогия с инструментом немного некорректна. Речь скорее о заточке инструмента, чем о дураках или запретах.
Как раз к месту.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 27. 06. 2011 [10:26]
|
|
almaz
Almaz Karimov
Contributor
Зареєстрован(а) с: 25.09.2008
Повідомлення: 516
|
Суть работы с ресурсами обычно доходит ещё при изучении основ программирования. Должен выполняться третий закон Ньютона. ) Противодействие равно действию.
Задача освобождения ресурсов при прерывании потока формализуется просто. Любой отдельно взятый поток последовательно выполняет открытия ресурсов (блокировки, выделения и др.), далее произведя с ресурсами некоторые действия выполняет закрытия (разблокировки, освобождения и др.). Задача сводится к помещению в стек завершающей процедуры при открытии ресурса (pthread_cleanup_push) и удалению завершающей процедуры из стека при закрытии ресурса (pthread_cleanup_pop). Естественно, поток при открытии-закрытии ресурсов и работе со стеком завершающих процедур прерывать нельзя. Для чего соответствующие участки кода берутся в "скобки" (pthread_setcancelstate, pthread_setcanceltype), внутри которых прерывание потока невозможно. Так как большая часть кода представляет собой обработку открытых ресурсов, прерывание потока возможно в широком диапазоне мест. К тому же открытия-закрытия ресурсов происходят быстро, а именно обработка занимает значительное время. Список функций, имеющих точки прерывания: http://www.kernel.org/doc/man-pages/online/pages/man7/pthreads.7.html
Сложность представляет нахождение в исходном коде точек "открытия-закрытия" ресурсов. Ещё "блокировки-разблокировки" ресурсов между потоками...
[Повідомлення редагувалось 1 раз(ів), останній раз 27.06.2011 в 10:28.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
|
