Які уроки ви засвоїли з проекту, який майже / насправді провалився через погану багатопотоковість? [зачинено]

Які уроки ви засвоїли з проекту, який майже / насправді провалився через погану багатопотоковість?

Іноді, рамка накладає певну модель різьблення, яка ускладнює порядок.

Що стосується мене, я ще не оговтався після останньої невдачі, і я відчуваю, що мені краще не працювати над тим, що стосується багатопотокової роботи в цих рамках.

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

Я не в змозі обробити графічний інтерфейс, в якому певна робота може бути виконана лише на строго серіалізованій нитці ("головна нитка"), а інша робота може бути виконана лише на будь-якій потоці, окрім головної нитки ("робочі нитки"), і де дані та повідомлення повинні рухатись у всіх напрямках між N компонентами (повністю пов'язаний графік).

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

Щось про проект: кількість ідентифікаторів повідомлень (цілих значень, які описують значення події, яка може бути надіслана до черги повідомлень іншого об'єкта, незалежно від потоку), налічує кілька тисяч. Унікальних рядків (повідомлень користувачів) також налічується близько тисячі.

Додано

Найкраща аналогія, яку я отримав від іншої команди (не пов'язаної з моїми минулими чи теперішніми проектами), - це "занести дані в базу даних". ("База даних" з посиланням на централізацію та атомні оновлення.) У графічному інтерфейсі, який фрагментований на кілька представлень, які працюють на одній "головній нитці", а всі важкі підйоми, що не є GUI, виконуються в окремих робочих потоках, дані програми повинні мати зберігатись в єдиній площині, яка діє як База даних, і нехай "База даних" обробляє всі "атомні оновлення", що включають нетривіальні залежності даних. Всі інші частини графічного інтерфейсу просто обробляють малюнок екрану і більше нічого. Частини користувальницького інтерфейсу можуть кешувати матеріали, і користувач не помітить, якщо він затягся на частку секунди, якщо він розроблений належним чином. Ця "база даних" також відома як "документ" в архітектурі перегляду документів. На жаль - ні, мій додаток насправді зберігає всі дані у Переглядах. Я не знаю, чому так було.

Співробітники:

(учасникам не потрібно використовувати реальні / особисті приклади. Уроки з анекдотичних прикладів, якщо ви вважаєте їх самими достовірними, також вітаються.)

Моє улюблене заняття - дуже важко виграно! - це те, що в багатопотоковій програмі планувальник - підлий свиня, який ненавидить вас. Якщо справи можуть піти не так, вони будуть, але несподівано. Зробіть щось не так, і ви будете переслідувати дивних heisenbugs (адже будь-який інструмент, який ви додасте, змінить таймінги і дасть вам інший малюнок запуску).

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

Ось декілька основних уроків, про які я зараз можу подумати (не з провальних проектів, а з реальних питань, що спостерігаються на реальних проектах):

• Постарайтеся уникати блокування дзвінків, тримаючи спільний ресурс. Поширений шаблон тупикового зв'язку - це те, що схоплює файли mutex, здійснює зворотний дзвінок, блокує зворотний виклик на цьому ж файлі.
• Захистіть доступ до будь-яких спільних структур даних за допомогою мутексу / критичного розділу (або використовуйте блоки, не заблоковані, але не вигадуйте свої власні!)
• Не допускайте атомності - використовуйте атомні API (наприклад, InterlockedIncrement).
• RTFM щодо безпеки потоку бібліотек, об'єктів або API, які ви використовуєте.
• Скористайтеся наявними примітивами синхронізації, наприклад, подіями, семафорами. (Але звертайте пильну увагу, використовуючи їх, якщо ви знаєте, що ви перебуваєте в хорошому стані. Я бачив багато прикладів подій, що сигналізують про неправильний стан, так що події чи дані можуть загубитися)
• Припустимо, потоки можуть виконуватися одночасно та / або в будь-якому порядку, і цей контекст може перемикатися між потоками в будь-який час (якщо тільки в ОС, яка дає інші гарантії).

• Весь ваш GUI- проект слід викликати лише з основного потоку . В основному, ви не повинні ставити жодного (.net) "виклику" у вашому графічному інтерфейсі. Багатопотоковість повинна застрявати в окремих проектах, які працюють з більш повільним доступом до даних.

Ми успадкували частину, де проект GUI використовує десяток ниток. Це не дає нічого, крім проблем. Тупики, гоночні проблеми, перехресні дзвінки GUI ...

У Java 5 і пізніших версіях є виконавці, які покликані полегшити життя при роботі з програмами стилю для багатопотокового з'єднання.

Використовуйте ті, це зніме сильний біль.

(і так, це я дізнався з проекту :))

Я маю досвід роботи у вбудованих системах у реальному часі. Ви не можете перевірити відсутність проблем, спричинених багатопотоковою читанням. (Ви можете іноді підтвердити свою присутність). Кодекс повинен бути вірно правильним. Тож найкраща практика щодо будь-якої взаємодії потоків.

• Правило №1: KISS - Якщо вам не потрібна нитка, не обертайте її. Максимально серіалізуйте.
• Правило №2: Не порушуйте №1.
• # 3 Якщо ви не можете довести через огляд, що це правильно, це не так.

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

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

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

Спробуйте зробити це ще раз.

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

Я думаю, що налагодження - це справді те, що ускладнює. Я можу налагоджувати багатопотоковий код за допомогою VS, але я дійсно в повній втраті, якщо мені доведеться використовувати gdb. Моя вина, напевно.

Ще одна річ, про яку ви дізнаєтесь більше - це заблокувати вільні структури даних.

Я думаю, що це питання можна реально покращити, якщо вказати рамки. Приклади потоків .NET потоків і фонові працівники дійсно відрізняються, наприклад, від QThread. Завжди є кілька платформ, що стосуються конкретних платформ.

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