Лекції

Розбираємося, чому гонки можливі й у корутинах: конкурентне виконання на Dispatchers . Default, проблеми shared mutable state, складені операції на кшталт counter ++ і пастка check-then-act. Вчимося формулювати інваріанти (наприклад, tickets >= 0), виділяти критичні секції, а також будуємо навчальний полігон TicketOffice для наступних лекцій.

Розбираємо, навіщо корутинам потрібен Mutex і як правильно виділяти критичну секцію через withLock: захищаємо не «змінну», а інваріант, тримаємо замок мінімально можливий час, уникаємо антипатерна runBlocking усередині допоміжних функцій і будуємо потокобезпечний реєстр витрат ( ExpenseLedger) із безпечним читанням через snapshot().

Розбираємо атомарні типи з java.util.concurrent.atomic у Kotlin/JVM: як AtomicInteger робить інкремент безпечним без Mutex, чому звʼязка get() → set() не «склеюється» в атомарність, як працює CAS через compareAndSet і чому AtomicReference<T> майже завжди варто поєднувати з незмінюваним станом (через copy()). Наприкінці — мапа вибору інструмента й типові помилки.

Розбираємо підхід confinement у корутинах: як прибрати гонки «за конструкцією», коли змінюваний стан належить одному власнику, а всі інші спілкуються з ним через повідомлення. На практиці будуємо actor на основі Channel: мінімальний лічильник без Mutex, типізований протокол команд через sealed class, кілька відправників, запит/відповідь через SendChannel, правила коректного завершення ( Stop vs close()) і набір типових помилок.

Розбираємо три «антипрогреси» в конкурентному коді на Kotlin-корутинах: deadlock (взаємне очікування), livelock (активна метушня без результату) і starvation (голодування задач). На прикладах із Mutex, withLock і tryLock() показуємо, як помилки народжуються через порядок захоплення, надто довгі критичні секції та «ввічливі» повторні спроби. А далі закріплюємо це правилами: єдиний порядок за id, короткий withLock, бекоф і (коли можливо) перехід до дизайну confinement/ actor.