Словник для умов гонки і помилок одночасності

Одночасні помилки є номінально важко відтворити і навіть важче пояснити чітко, що робить словник навколо них надзвичайно важливим. Сказати «це лускате» або «це трапляється іноді» не допомагає колегі розуміти про проблему — назвати конкретний механізм (гоночний стан, затор, голодування) вказує безпосередньо на клас необхідного виправлення.

Фундаментальні поняття

1. Гоночні умови

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

** Використання: ** * “Це класична умова перегонів — два запити можуть прочитати один і той же баланс, перш ніж один з них записає оновлення, отже, одне оновлення беззвучно перезапише інше.” *

2. критичний розділ

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

** Використання: ** * “Цей блок читає і змінює спільний лічильник без будь- якого блокування навколо нього — його слід розглядати як критичну секцію.” *

3-й. Взаємне виключення (mutex)

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

** Використання: ** * “Ми обгорнули критичну секцію у mutex, щоб тільки один працівник міг оновити запис спільного кешу водночас.” *

4. тупик

Стан, коли дві або більше потоків очікують на ресурс, що належить іншому потоку, так, що жоден з них не може продовжити роботу.

** Використання: ** * “Ми потрапили у тупик, тому що нитка А тримає блокування 1 і чекає на блокування 2, а нитка Б тримає блокування 2 і чекає на блокування 1.” *

Лайвлок

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

** Використання: ** “Обидві повторні спроби циклів відступали на користь одне одного і жоден з них не продовжувався — це livelock, а не deadlock, оскільки жоден з потоків не застряг у очікуванні.”

Визначення та діагностика

Недетермінізм

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

** Використання: ** “Недетермінізм цього тесту походить від неупорядкованої ітерації над набором одночасних працівників — порядок виводу не гарантований.”

7-й. Відтворюваність (баги одночасності)

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

** Використання: ** * “Відтворюваність цієї помилки може бути один раз на двадцять запусків локально, але це відбувається майже кожен раз під виробничою нагрузкою, що вказує на гонку з чутливістю до часу.” *

Перегони даних

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

** Використання: ** * « Система очищення потоків позначила перегони даних у цій змінній — дві програми- керівники записують до неї без блокування між ними. » *

9. Атомність

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

** Використання: ** “Це збільшення не є атомарним — це насправді читання, додавання і запис, і інша нитка може переплітатися посередині цих трьох кроків.”

10-й. Связано с прошлым

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

** Використання: ** * “Без явного зв’ язку « відбувається перед », встановленого операцією блокування або каналу, немає гарантії, що інша нитка бачить запис взагалі.” *

Звичайні виправлення і шаблони

11-й. Замок (замок)

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

** Використання: ** * “Ми бачимо високу конкуренцію за блокування на цьому одному глобальному блокуванні — розділення його на блокування на шарі повинно зменшити кількість потоків, які чекають один на одного.” *

12-й. Оптимістичне керування одночасністю

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

** Використання: ** “Замість блокування рядка для всієї транзакції, ми використовуємо оптимістичний контроль одночасності зі стовпчиком версії, і повторюємо спробу, якщо версія змінилася.”

13. Нездатність

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

** Використання: ** * “Ми зробили цю кінцеву точку ідемпотентною за допомогою ідентифікатора запиту, тому повторний запит з мережі з нестабільним зв’ язком не буде вдвічі обкладати клієнта.” *

14. Голод

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

** Використання: ** * “Цей працівник з низьким пріоритетом переживає голодування — завдання з більшим пріоритетом продовжують перескокувати чергу, отже, його ніколи не буде заплановано.” *

15-й. Сі-Сі-Сі (фр

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

** Використання: ** * “Ми замінили лічильник, заснований на блокуванні, циклом порівняння і обміну, який уникає повного блокування при низькій конкуренції.” *

Розповідь про спільні вчинки

16. Безпека ниток

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

** Використання: ** “Цей клас не є безпечним для потоків — документація не говорить про це явно, але він явно припускає доступ з одним потоком.”

17. повернення

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

** Використання: ** “Ця обробка не є реентрантною — повторне викликання її під час виконання пошкоджує її внутрішній буфер, що саме і сталося, коли сигнал був викликаний двічі.”

18. вікно гонки

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

** Використання: ** * « Вікно перегонів тут триває лише декілька мілісекунд між перевіркою і записом, саме тому ця помилка з’ являється, можливо, раз на десять тисяч запитів. » *

19-й. Проверь и действуй

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

** Використання: ** *“Це класична помилка типу « перевірити — і діяти » — ми перевіряємо, чи існує файл, а потім створюємо його, але інший процес може створити його між цими двома кроками.” *

20-х років. Розірвано читання/ запис

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

** Використання: ** * “Ми побачили розірване читання на цьому 64- бітному лічильнику на 32- бітній платформі, оскільки дві половини значення можна прочитати у дещо різних моментах.” *

Ключеві моменти

• Називайте конкретний механізм (гоночний стан, затор, живий затор, голодування), а не кажучи, що помилка « іноді трапляється » — точні назви пунктів безпосередньо в класі виправлення.
• Розрізняти застілку від livelock точно — у першій з цих ситуацій потоки справді застрягли у очікуванні, у другій — потоки зайняті, але не виконують жодних дій.
• Досягти ідемпотентності і оптимістичного контролю одночасності як конкретних шаблонів, а не просто « додати блокування », оскільки важке блокування вводить власні проблеми з суперечністю.
• Визнайте check-then-act як специфічний, спільний анти-патерн, який варто назвати явно в перегляді коду, а не описувати нечітко як «проблему часу»
• Фрейм низька відтворюваність як доказ вузького вікна гонки, а не як причина для зниження пріоритету помилки - чутливі до часу помилки часто стають набагато частішими під виробничою нагрузкою.