На що ви звертаєте увагу при налагодженні тупиків?

Останнім часом я працюю над проектами, які активно використовують різьблення. Я думаю, що я все гаразд розробляю; якомога більше використовувати дизайн без громадянства, заблокувати доступ до всіх ресурсів, які потребують більше ніж одна нитка і т. д. Мій досвід функціонального програмування дуже допоміг цьому.

Однак, читаючи код нитки інших людей, я плутаюся. Я зараз налагоджую тупик, і оскільки стиль кодування та дизайн відрізняються від мого особистого стилю, мені важко бачити потенційні умови тупику.

На що ви звертаєте увагу при налагодженні тупиків?

Якщо ситуація справжня тупикова ситуація (тобто два потоки містять два різних блокування, але принаймні одна нитка хоче заблокувати іншу нитку), то потрібно спочатку відмовитися від усіх попередніх уявлень про те, як замовлення блокування потоків. Не припускайте нічого. Ви можете видалити всі коментарі з коду, який ви шукаєте, оскільки ці коментарі можуть змусити вас повірити в те, що не відповідає дійсності. Важко наголосити на цьому досить: припускати нічого.

Після цього визначте, які замки утримуються, коли нитка намагається заблокувати щось інше. Якщо можете, переконайтесь, що нитка розблокується у зворотному порядку від блокування. Ще краще, переконайтеся, що нитка містить один замок одночасно.

Наполегливо працюйте над виконанням потоку та вивчайте всі події блокування. При кожному блокуванні визначте, чи містить нитка інші замки, і якщо так, то за яких обставин інший потік, виконуючи аналогічний шлях виконання, може потрапити до розглядуваної події блокування.

Звичайно, можливо, ви не знайдете проблеми, перш ніж у вас не вистачить часу або грошей.

1. Як говорили інші ... якщо ви можете отримати корисну інформацію для ведення журналів, то спробуйте спочатку, як це найлегше зробити.

2. Визначте замки, які задіяні. Змініть усі мутекси / семафори, які вічно чекають, щоб приурочити очікування ... щось смішне довге, як 5 хвилин. Увімкніть помилку, коли вона вичерпається. Це, принаймні, вкаже вам на бік одного із замків, який бере участь у питанні. Залежно від мінливості часу, можливо, вам пощастить і знайдете обидва блокування через кілька запусків. Використовуйте коди / умови відмови функції для реєстрації сліду стека псевдо після того, як приурочене очікування не визначить, як ви потрапили туди в першу чергу. Це має допомогти вам визначити тему, яка бере участь у питанні.

3. Ще одна річ, яку ви можете спробувати, - це створення бібліотеки для обгортки навколо ваших служб mutex / semaphore. Відслідковуйте, які потоки мають кожен мутекс та які нитки очікують на мютекс. Створіть моніторну нитку, яка перевіряє, як довго блокуються потоки. Запустити деяку розумну тривалість та скинути інформацію про стан, яку ви відстежуєте.

У якийсь момент буде потрібна звичайна перевірка старого коду.

Першим кроком (як каже Петер) є ведення журналу. Хоча на моєму досвіді це часто проблематично. При важкій паралельній обробці це часто неможливо. Мені довелося один раз налагоджувати щось подібне з нейронною мережею, яка обробляла 100 К вузлів в секунду. Помилка сталася лише через декілька годин, і навіть один рядок виведення продукції загальмував настільки, що пройшло б кілька днів. Якщо журнал можливий, концентруйтеся менше на даних, але більше на потоці програми, поки не дізнаєтеся, в якій частині це відбувається. Просто простий рядок на початку кожної функції, і якщо ви можете знайти потрібну функцію, розділіть її на менші шматки.

Інший варіант - видалення частин коду та даних для локалізації помилки. Можливо, навіть написати якусь невелику програму, яка займає лише деякі з класів і виконує лише найосновніші тести (все-таки в декількох темах звичайно). Видаліть все, що стосується gui, наприклад будь-який висновок про фактичний стан обробки. (Я виявив, що інтерфейс користувача є джерелом помилки досить часто)

У своєму коді намагайтеся дотримуватися повного логічного потоку управління між ініціалізацією блокування та відпусканням його. Поширеною помилкою може бути блокування на початку функції, розблокування в кінці, але наявність умовного оператора повернення десь посередині. Винятки можуть також запобігти випуску.

Мої найкращі друзі друкували журнали / журнали у цікавих місцях у коді. Зазвичай вони допомагають мені краще зрозуміти, що насправді відбувається в додатку, не порушуючи часу між різними потоками, що може запобігти відтворенню помилки.

Якщо це не вдається, мій єдиний метод, який залишився, дивиться на код і намагається створити ментальну модель різних потоків і взаємодій, і намагається продумати можливі шалені способи досягти того, що, мабуть, сталося :-) Але я не вважаю себе дуже досвідченим вбивцею. Сподіваюсь, інші зможуть дати кращі ідеї, з яких я також можу навчитися :-)

Перш за все, спробуйте знайти автора цього коду. Ймовірно, він матиме ідею того, що написав. навіть якщо ви двоє не можете точно визначити проблему, розмовляючи, принаймні ви можете сісти з ним, щоб точно визначити частину тупикового кута, що буде набагато швидше, ніж ви зрозумієте його / її код без допомоги.

Якщо цього не сказати, як сказав Петер Тьорк, то, мабуть, це шлях. Наскільки я знаю, «Налагоджувач» зробив погану роботу в багатопотоковому середовищі. спробуйте знайти, де знаходиться замок, зрозуміти, які ресурси чекають, і в якому стані відбувається перегоновий стан.

Це питання мене приваблює;) Перш за все, вважайте себе щасливим, оскільки ви змогли послідовно відтворювати проблему на кожному етапі. Якщо ви отримуєте один і той же виняток з однаковим стеком сліду кожного разу, тоді він повинен бути досить прямим. Якщо ні, то не довіряйте стек-трасі настільки сильно, а просто стежте за доступом до глобальних об'єктів та його станом під час виконання.

Якщо вам доведеться налагоджувати тупики, ви вже в біді. Як правило, використовуйте замки в найкоротші терміни - або зовсім не, якщо можливо. Слід уникати будь-якої ситуації, коли ви берете замок і переходите на нетривіальний код.

Звичайно, це залежить від вашого програмного середовища, але ви повинні дивитися на речі, як послідовні черги, які можуть дозволяти вам отримати доступ до ресурсу лише з одного потоку.

І тоді є стара, але непогрішна стратегія: призначте "рівень" кожному блокуванню, починаючи з рівня 0. Якщо ви берете замок рівня 0, вам не дозволено жодних інших блокувань. Після зняття блокування рівня 1 ви можете зробити блокування рівня 0. Після вимкнення блокування 10 рівня ви можете взяти замки на рівні 9 або нижче тощо.

Якщо вам це неможливо зробити, вам потрібно виправити свій код, оскільки ви зіткнетесь з тупиками.