Чи варто подбати про умови перегонів, які майже напевно не мають шансів виникнути?

Розглянемо щось на зразок програми GUI, де головний потік оновлює інтерфейс користувача миттєво, а інший потік запитує дані по мережі або щось, на що гарантовано потрібно 5-10 секунд, щоб закінчити завдання.

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

Які ваші думки? Чи є гарною практикою програмування керування умовами перегонів у таких статистично неможливих ситуаціях? чи було б абсолютно непотрібним або навіть контрпродуктивним додати більше рядків коду, щоб перешкодити читанню?

Якщо це дійсно подія 1 на 10 ^ 55, кодувати його не потрібно. Це означає, що якби ви робили операцію 1 мільйон разів на секунду, ви отримували б одну помилку кожні 3 * 10 ^ 41 рік, що, приблизно, в 10 ^ 31 раз перевищує вік Всесвіту. Якщо ваша програма має помилку лише один раз на кожні трильйон трильйонів мільярдів віків Всесвіту, це, мабуть, досить надійно.

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

З точки зору витрат і вигод, слід писати додатковий код лише тоді, коли він отримує вам достатню вигоду.

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

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

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

Що стосується ймовірностей, ви були б здивовані. У минулому році у мене був звіт про помилку щодо стану гонки, що я не міг відтворити тисячі автоматизованих спроб, але одна система одного клієнта бачила це постійно. Ділова цінність витрачати 5 хвилин, щоб виправити його зараз, і, можливо, усунення неполадок "неможливої" помилки при встановленні клієнта, робить вибір не потрібним.

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

а деякі інші потоки - це опитування даних по мережі або щось, на що гарантовано знадобиться 5-10 секунд, щоб закінчити завдання.

Поки хтось не введе шар кешування для підвищення продуктивності. Раптом інший протектор закінчився миттєво, і стан гонки проявляється частіше.

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

Завжди фіксуйте умови перегонів, якщо ви їх розпізнаєте.

Простий проти правильний.

У багатьох випадках простота козирує правильність. Це питання вартості.

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

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

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

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

Навіть якщо умова перегонів має щось на зразок 10 ^ (- 80) шансів статися випадковим чином , цілком може статися так, що рішучий нападник має гідні шанси створити такі умови навмисно та штучно.

Therac-25!

Розробники проекту Therac-25 були досить впевнені в термінах між інтерфейсом користувача та проблемою, пов’язаною з інтерфейсом, у терапевтичній машині XRAY.

Вони не повинні були бути.

Дізнатися більше про цю знамениту катастрофу програмного забезпечення на смерть та смерть можна за посиланням:

http://www.youtube.com/watch?v=izGSOsAGIVQ

або

http://en.wikipedia.org/wiki/Therac-25

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

Якщо ви вирішили побудувати свій код до останнього (і це звучить так, як у вас є), слід розглянути закон Мура, який може легко знімати кілька нулів кожні кілька років, оскільки комп'ютери всередині або поза вашою системою стають швидшими. Якщо ви відправляєте тисячі примірників, зніміть більше нулів. Якщо користувачі роблять цю операцію щодня (або щомісяця) протягом багатьох років, зніміть ще кілька. Якщо він використовується там, де доступне волокно Google, що тоді? Якщо сміття з інтерфейсу користувача збирає середину роботи графічного інтерфейсу, чи впливає це на гонку? Чи використовуєте ви відкритий код або бібліотеку Windows за графічним інтерфейсом? Чи можуть оновлення там впливати на терміни?

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

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

Здається, що обчислення ймовірності відбувається від когось іншого. Чи знають вони ваш код і чи знаєте ви їх достатньо, щоб довіритися, що помилки не було? Якщо я обчислив 99,99997% надійності для чогось, я також міг би подумати про свої статистичні заняття в коледжі і пам’ятати, що я не завжди отримував 100% і відступав зовсім небагато відсотків на своїх власних особистих оцінках надійності.

було б абсолютно непотрібним або навіть контрпродуктивним додати більше рядків коду, щоб перешкодити читанню?

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

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

Це залежатиме від контексту. Якщо це випадкова гра на iPhone, напевно, ні. Мабуть, система управління польотом для наступного пілотованого космічного апарату. Все залежить від того, які наслідки будуть, якщо «поганий» результат відбудеться, виміряний із розрахунковою вартістю його виправлення.

На такі типи питань рідко зустрічається відповідь "один розмір, який відповідає всім", оскільки вони не є питаннями програмування, а натомість питань економіки.

Так, очікуйте несподіваного. Я провів години (у інших народних кодах ^^), відслідковуючи умови, які ніколи не повинні відбуватися.

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

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

Просто виправте це.

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

Деякий клієнт десь вирішить одного дня запустити щось, що зависає весь час процесора для «швидкої» нитки, залишаючи повільний потік, і вам буде шкода :)

Якщо ви визнали малоймовірною умову гонки, принаймні задокументуйте це у коді!

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

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

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

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

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

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

Receive event from device:
{
    Record event details.
    Enqueue event in the queuing thread.
    Acknowledge the event.
}

Queueing thread receives an event:
{
    Retrieve event details.
    Process event.
    Send next command to device.
}

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

Враховуючи, що це стосується лише одного замовника в одній конфігурації, я ганебно ставлю те, Thread.Sleep(1000)де проблема. З цього часу проблем не було.