Mutex v mobilních aplikacích — co to je, princip fungování a použití vzájemného vyloučení

Co je Mutex?

Mutex (zkratka z Mutual Exclusion — vzájemné vyloučení) — je synchronizační objekt, který řídí přístup ke sdílenému zdroji ve vícevláknovém prostředí. Když vlákno vstoupí do kritické sekce, získá Mutex. Pokud se jiné vlákno pokusí získat stejný Mutex, je převedeno do stavu čekání, dokud není zámek uvolněn prvním vláknem.

Architektura Mutex sahá k operačnímu systému THE, vyvinutému Edsgerem Dijkstrou v roce 1965. Právě Dijkstra zavedl koncept semaforů, z nichž se později Mutex vyčlenil jako zvláštní případ — binární semafor s podporou vlastnictví. Moderní operační systémy (Linux, Windows, Android) implementují Mutex na úrovni jádra, což zajišťuje správnou synchronizaci i mezi různými procesy.

Klíčovou vlastností Mutex je ownership (vlastnictví). Pouze vlákno, které mutex získalo, jej může uvolnit. To odlišuje Mutex od binárního semaforu, kde jakékoli vlákno může provést signál (V-operaci). Vlastnictví zabraňuje náhodnému uvolnění zámku jiným vláknem, což činí Mutex bezpečnějším pro typické scénáře synchronizace v mobilním vývoji. Podle Android Developer Docs (Processes and Threads, 2024) může použití Mutex místo synchronized zvýšit výkon o 30% při vysoké konkurenci.

Jak Mutex funguje

Stavy a operace

Mutex je v jednom ze dvou stavů: zamčený (locked) — získaný vláknem; volný (unlocked) — nezískaný. Dvě základní operace — lock() (získání) a unlock() (uvolnění). Pokud je Mutex již získán, vlákno volající lock() je blokováno až do uvolnění. V JVM přechází blokované vlákno do stavu BLOCKED a nespotřebovává CPU.

Plánování čekajících vláken

Když je Mutex uvolněn, systém vybírá, které z čekajících vláken získá zámek. Při nespravedlivém (non-fair) plánování může volba padnout na vlákno, které právě uvolnilo mutex — to zvyšuje propustnost, ale může vést k Starvation (hladovění). Spravedlivý (fair) plánovač používá frontu FIFO: první čekající vlákno získá zámek jako první. ReentrantLock(true) implementuje právě tento mechanismus.

Rekurzivní získávání (Reentrancy)

Většina implementací Mutex v Java/Kotlin podporuje rekurzivní (reentrant) získávání. Pokud vlákno již Mutex vlastní a znovu zavolá lock(), operace je úspěšná — Mutex neblokuje sám sebe. Počítadlo rekurze se zvyšuje a vlákno musí zavolat unlock() tolikrát, kolikrát lock(). To je důležité pro rekurzivní volání a vnořené kritické sekce.

Příklad použití Mutex v kódu Kotlin

Uvažujme typický úkol — ochranu sdíleného čítače před Race Condition pomocí ReentrantLock (klasický Mutex v Java/Kotlin). Bez Mutex by kód dával nesprávný výsledek; s Mutex všech 1000 vláken zaručeně zvyšuje hodnotu čítače.

import java.util.concurrent.locks.ReentrantLock

class MutexCounter {
    private val mutex = ReentrantLock()
    private var count = 0

    fun increment() {
        mutex.lock()
        try {
            count++  // kritická sekce
        } finally {
            mutex.unlock()  // povinný finally
        }
    }

    fun getCount(): Int {
        mutex.lock()
        try {
            return count
        } finally {
            mutex.unlock()
        }
    }
}

fun main() = runBlocking {
    val counter = MutexCounter()
    val jobs = List(1000) {
        launch(Dispatchers.Default) {
            counter.increment()
        }
    }
    jobs.forEach { it.join() }
    println(counter.getCount())  // Vždy 1000
}

Všimněte si bloku finally — povinného vzoru při práci s Mutex. Pokud v kritické sekci dojde k výjimce, unlock() se nevyvolá a Mutex zůstane navždy zamčený — to vede k Deadlock. Blok finally zaručuje uvolnění Mutex při jakémkoli výsledku provedení sekce.

Alternativní přístup v Kotlin — použití rozšiřující funkce withLock, která automaticky zpracovává lock/unlock s finally.

fun increment() {
    mutex.withLock {  // lock + try/finally automaticky
        count++
    }
}

fun getCount(): Int = mutex.withLock { count }

Mutex vs Semaphore vs Monitor

Tyto tři synchronizační mechanismy jsou často zaměňovány, ačkoli mají různé vlastnosti a oblasti použití. Mutex — binární, s vlastnictvím. Semaphore — čítač povolení, bez vlastnictví. Monitor — mechanismus vysoké úrovně kombinující Mutex s podmínkovými proměnnými (condition variables). Porozumění rozdílům je kritické pro výběr správného nástroje pro konkrétní úkol.

Kdy zvolit Mutex: je třeba chránit jeden zdroj před současným přístupem — například sdílenou kolekci, soubor nebo čítač. Kdy zvolit Semaphore — je třeba omezit počet současných přístupů do fondu zdrojů, například fond databázových spojení s 5 připojeními. Kdy zvolit Monitor — je třeba synchronizace s podmíněným čekáním, například fronta producer-consumer přes wait/notify. V moderním Android vývoji je synchronized často nahrazován ReentrantLock nebo kotlinx.coroutines Mutex.

Typické chyby při použití Mutex

Zapomenutý unlock v finally

Nejčastější chyba — absence bloku finally pro volání unlock(). Pokud v kritické sekci dojde k výjimce, Mutex zůstane zamčený a ostatní vlákna čekají věčně. I když jste si jisti, že výjimky jsou nemožné — vždy používejte try/finally nebo withLock. To je princip defensive programming, obzvláště důležitý v mobilním vývoji, kde výjimky mohou vzniknout z důvodu nedostatku paměti nebo Configuration Changes.

Různé pořadí získávání Mutex

Když je v aplikaci používáno více Mutex, je kritické stanovit jednotné pořadí jejich získávání. Pokud Vlákno A získává M1 → M2 a Vlákno B získává M2 → M1, vzniká Deadlock. Ve velkých projektech (přes 50 tisíc řádků kódu) je pořadí zámků dokumentováno v architektonickém rozhodnutí a kontrolováno lintery. Nástroj Lock Checker v IntelliJ IDEA automaticky detekuje nekonzistentní pořadí získávání zámků.

Příliš dlouhá kritická sekce

Držení Mutex déle než 1-2 milisekundy — známka nesprávného návrhu. Kritická sekce by měla obsahovat pouze minimálně nutné operace. Síťové požadavky, souborový vstup/výstup a složité výpočty by měly být prováděny mimo uzamčený blok. V Androidu vede dlouhé držení zámku ve vláknu UI k přeskakování snímků (jank) a ANR. Použijte ReadWriteLock, pokud kritická sekce sestává převážně z operací čtení.

Mutex v Kotlin Coroutines

Knihovna kotlinx.coroutines poskytuje vlastní implementaci Mutex, která se zásadně liší od klasického ReentrantLock. Hlavní rozdíl — suspending Mutex neblokuje vlákno OS, ale pozastavuje korutinu až do uvolnění zámku. To znamená, že vlákno může vykonávat jiné korutiny, zatímco aktuální čeká na Mutex.

import kotlinx.coroutines.sync.Mutex
import kotlinx.coroutines.sync.withLock

class CoroutineCounter {
    private val mutex = Mutex()
    private var count = 0

    suspend fun increment() {
        mutex.withLock {  // suspending — neblokuje vlákno
            count++
        }
    }

    suspend fun getCount(): Int = mutex.withLock { count }
}

Klíčové vlastnosti kotlinx Mutex: nerekurzivnost (non-reentrant) — na rozdíl od ReentrantLock, korutina nemůže znovu získat Mutex, který již vlastní. Pokud je to nutné, použijte Semaphore(1) místo Mutex. Kromě toho je Mutex z kotlinx.coroutines neblokující: používá pozastavení pomocí suspend, což umožňuje neblokovat vlákno fondu.

V praxi je suspending Mutex preferován před klasickým ReentrantLock v korutinovém kódu ze dvou důvodů: škálovatelnost — jedna korutina čeká na Mutex, zatímco vlákno obsluhuje jiné korutiny, což zvyšuje propustnost systému; absence BlockedThread — neplýtvá se prostředky na ukládání zásobníku blokovaného vlákna. Podle JetBrains (Kotlin Coroutines Guide, 2024) zvyšuje použití suspending Mutex propustnost o 40% při 100+ korutinách.