форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Проблема с самодиагностикой приложения..."
Сообщение от Aptimist (ok) on 02-Авг-04, 12:13  (MSK)
Самая главная часть проблемы в том, что я совершенно не представляю, как производится самотестирование приложения, особенно многопоточного, как у меня. Задача состоит в том, чтобы постоянно мониторить работу всех потоков и вовремя замечать, что, скажем, какой-нибудь поток заглох на кокой-то операции (мало ли, может с мьютексами какой косяк выскочит и он повиснет в попытке его заблокировать, а разблокировть будет не кому и т. п.), то есть сам поток не сможет крикнуть: хелп... Может кто-нибудь сталкивался с подобной задачей или знает, где почитать-поискать-посмотреть... очень нужно... Заранне благодарен.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "Проблема с самодиагностикой приложения..."
Сообщение от genie on 03-Авг-04, 02:17  (MSK)
Ispol'zui ne pryamye mutexy, a kakoi-nibud' wrapper, kotoryi pri kazhdom lock zanosit informaciu ob etom v spisok (vmeste so vremenem lock). Kazhdye n secund proveryai, chto v spsike net lockov starshe X secund - vot i vse. >Самая главная часть проблемы в том, что я совершенно не представляю, как >производится самотестирование приложения, особенно многопоточного, как у меня. >Задача состоит в том, чтобы постоянно мониторить работу всех потоков и вовремя >замечать, что, скажем, какой-нибудь поток заглох на кокой-то операции (мало ли, >может с мьютексами какой косяк выскочит и он повиснет в попытке >его заблокировать, а разблокировть будет не кому и т. п.), то >есть сам поток не сможет крикнуть: хелп... >Может кто-нибудь сталкивался с подобной задачей или знает, где почитать-поискать-посмотреть... очень нужно... > >Заранне благодарен.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "Проблема с самодиагностикой приложения..."
	Сообщение от Aptimist (ok) on 03-Авг-04, 11:41  (MSK)
	>Ispol'zui ne pryamye mutexy, a kakoi-nibud' wrapper, kotoryi pri kazhdom lock zanosit >informaciu ob etom v spisok (vmeste so vremenem lock). Kazhdye n >secund proveryai, chto v spsike net lockov starshe X secund - >vot i vse. Спасибо за дельное предложение. Только дело не только в мьютексах. Нужно вообще отслеживать, что данный поток ведёт себя как надо, и, что самое главное, это тем более нужно, если он себя так не ведёт или вообще никак не ведёт... Я вчера придумал один ход, сейчас отрабатываю детали. Коротко, если интересно, он состоит в том, что второй процесс в цикле через определённое время посылает сигналы первому (который мониторим), а у того по приходу ;-Р сигнала для каждого потока вызывается обработчик, который у каждого потока по идее (как я вычитал в умных книжках и в статьях умных дядей) свой и который соответсвенно заталкивает в очередь сообщений мезадж типа: надцать минут, полёт нормальный... хотя, впрочем, чего-то никак не получается воплотить эту идею в нормальной работающий код... но я не теряю надежды...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "Проблема с самодиагностикой приложения..."
	Сообщение от dimus (ok) on 03-Авг-04, 13:40  (MSK)
	А по-моему лучше поступить наоборот: пусть порожденные потоки посылают периодически сигнал главному, а кто не прислал сигнал вовремя - с тем поступить по законам военного времени :) А главный пусть только этой задачей и занимается. В принципе ты мог бы из этого главного потока понижать и повышать приоритеты других потоков. Вобщем, попробуй такой подход - может что получится. К сожалению я более конкретно ничего сказать не могу, т.к. имел дело только с потоками Win32, но вдруг так получится?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "Проблема с самодиагностикой приложения..."
	Сообщение от Aptimist (ok) on 03-Авг-04, 16:24  (MSK)
	>А по-моему лучше поступить наоборот: пусть порожденные потоки посылают периодически сигнал главному, >а кто не прислал сигнал вовремя - с тем поступить по >законам военного времени :) А главный пусть только этой задачей и >занимается. В принципе ты мог бы из этого главного потока понижать >и повышать приоритеты других потоков. Вобщем, попробуй такой подход - может >что получится. К сожалению я более конкретно ничего сказать не могу, >т.к. имел дело только с потоками Win32, но вдруг так получится? > Спасибо. Всё хорошо, но только не совсем подходит... :-( Представим такую ситуацию: поток производит считывание, скажем, через компорт данных с определённого устройства и это происходит следующим образом (так сделано в устройстве и драйвере): драйвер посылает запрос, если устройство отвечает, что данные ещё не готовы, драйвер скромно ждёт, регулярно теребя устройство, мол, всё или не всё, а оно ему постоянно: стрижка только начата... и такая канитель может продолжаться несколько минут... и пока она не завершиться поток не сможет сказать главному, мол, я ещё жив, не надо меня кремировать... мы можем только сообщить, мол, выхожу в открытый космос, то есть поток может крикнуть, что он начинает считывание данных, но пока он считывает мы не можем узнать, в каком состоянии находится поток... может он спокойно теребит устройство, а может устройство отрубили физически и драйвер повис в тщетных попытках до него достучаться (это я к примеру привёл)... вот такие ситуации необходимо отслеживать в первую очередь... пока ни одно из известных на данный момент решений не решает эту задачу полностью... :-( (ничего страшного, только второй день долблюсь... ещё не вечер...)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "Проблема с самодиагностикой приложения..."
	Сообщение от genie on 04-Авг-04, 02:25  (MSK)
	Nikakih problem - sozdai dlya kazhdogo potoka svoi placeholder, gde on budet stavit' statusy i predpolagaemoe vremya perehoda na sleduuschii status - esli eto vremya narusheno bolee chem na X (gde X mozhet hranitsya v tom zhe placeholder), to ubivai ego nafig. Takim obrazom kazhdyi thread sam opredelyaet, kogda zhe ego mozhno schitat' zombie. >>А по-моему лучше поступить наоборот: пусть порожденные потоки посылают периодически сигнал главному, >>а кто не прислал сигнал вовремя - с тем поступить по >>законам военного времени :) А главный пусть только этой задачей и >>занимается. В принципе ты мог бы из этого главного потока понижать >>и повышать приоритеты других потоков. Вобщем, попробуй такой подход - может >>что получится. К сожалению я более конкретно ничего сказать не могу, >>т.к. имел дело только с потоками Win32, но вдруг так получится? >> > >Спасибо. Всё хорошо, но только не совсем подходит... :-( >Представим такую ситуацию: поток производит считывание, скажем, через компорт данных с определённого >устройства и это происходит следующим образом (так сделано в устройстве и >драйвере): драйвер посылает запрос, если устройство отвечает, что данные ещё не >готовы, драйвер скромно ждёт, регулярно теребя устройство, мол, всё или не >всё, а оно ему постоянно: стрижка только начата... и такая канитель >может продолжаться несколько минут... и пока она не завершиться поток не >сможет сказать главному, мол, я ещё жив, не надо меня кремировать... >мы можем только сообщить, мол, выхожу в открытый космос, то есть >поток может крикнуть, что он начинает считывание данных, но пока он >считывает мы не можем узнать, в каком состоянии находится поток... может >он спокойно теребит устройство, а может устройство отрубили физически и драйвер >повис в тщетных попытках до него достучаться (это я к примеру >привёл)... вот такие ситуации необходимо отслеживать в первую очередь... пока ни >одно из известных на данный момент решений не решает эту задачу >полностью... :-( (ничего страшного, только второй день долблюсь... ещё не вечер...) >
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "Проблема с самодиагностикой приложения..."
	Сообщение от dimus (ok) on 05-Авг-04, 10:39  (MSK)
	Черт, это напоминает мне старуб недобрую Win 3.11 - там тоже если приложение зависало на какой-то долгоиграющей операции, то хрен что с ним сделаешь. Я не знаю, как это можно сделать, но идея такова: надо принудительно время от времени отбирать управление у данного потенциально зависшего потока и мониторить его состояние из другого, не зависшего потока. Примерно так делает операционка, переключаясь между разными задачами. Кстати, надо хорошо подумать, а как вообще можно определить из программы что поток завис, а не ждет, допустим, второго пришествия данных с компорта. Еще идея - это смотреть поступления данных без блокировки - посмотрел: есть данные - считал кусок и отвалился, сообщил процессу-пастуху. Нет данных - опять же отвалился, сообщил процессу-пастуху. Правда это будет выжирать ресурсы процессора, и причем нехило выжирать.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	10. "Проблема с самодиагностикой приложения..."
	Сообщение от hatta (ok) on 09-Авг-04, 22:35  (MSK)
	В линуксе можно смотреть для каждого потока файл в /proc/<pid>/status. Этот способ меганепортабельный: во-первых для каждой операционки свой формат файловой системы /proc и если во freebsd, например, можно включить линуховый формат, то не факт, что это заработает где-то еще. Во-вторых он непереносим даже в пределах линукса: для последнего есть куча реализаций posix threads (я так понимаю, речь идет именно о posix threads, хотя какие-то драйверы...): http://www.ibiblio.org/pub/Linux/docs/faqs/Threads-FAQ/html/ThreadLibs.html и для работы моего способа нужны именно потоки 1:1. Кроме того, я не знаю, как определить для каждого потока его PID, что-то мне кажется, что getpid() не сделает того, что от него ожидается.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

7. "Проблема с самодиагностикой приложения..."
Сообщение от Андрей (??) on 05-Авг-04, 18:35  (MSK)
Очень интересная проблемма. Жаль помочь ничем не могу, но прочитал с удовольствием.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

8. "Проблема с самодиагностикой приложения..."
Сообщение от Андрей (??) on 05-Авг-04, 18:39  (MSK)
Кстати, может (если есть исходники драйвера) вставить туда послание сигнала родителю, типа всё ок и тогда проблема с тем, что дочерний поток не может послать сигнал родительскому, вроде, исчезает.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	9. "Проблема с самодиагностикой приложения..."
	Сообщение от dimus (ok) on 09-Авг-04, 10:32  (MSK)
	Мысль о модернизации драйвера по-моему очень здравая. Это должно решить все проблемы.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

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