Mutex w aplikacjach mobilnych — co to jest, zasada działania i zastosowanie wzajemnego wykluczania

Co to jest Mutex?

Mutex (skrót od Mutual Exclusion — wzajemne wykluczanie) — to obiekt synchronizacji, który zarządza dostępem do współdzielonego zasobu w środowisku wielowątkowym. Gdy wątek wchodzi do sekcji krytycznej, przejmuje Mutex. Jeśli inny wątek próbuje przejąć ten sam Mutex, zostaje przełączony w stan oczekiwania do momentu zwolnienia blokady przez pierwszy wątek.

Architektura Mutex wywodzi się z systemu operacyjnego THE, opracowanego przez Edsgera Dijkstrę w 1965 roku. To właśnie Dijkstra wprowadził koncepcję semaforów, z których później wyodrębniono Mutex jako szczególny przypadek — semafor binarny z obsługą własności. Nowoczesne systemy operacyjne (Linux, Windows, Android) implementują Mutex na poziomie jądra, co zapewnia prawidłowe działanie synchronizacji nawet między różnymi procesami.

Kluczową właściwością Mutex jest ownership (własność). Tylko wątek, który przejął muteks, może go zwolnić. To odróżnia Mutex od semafora binarnego, gdzie każdy wątek może wykonać sygnał (operację V). Własność zapobiega przypadkowemu zwolnieniu blokady przez inny wątek, co czyni Mutex bezpieczniejszym dla typowych scenariuszy synchronizacji w programowaniu mobilnym. Według Android Developer Docs (Processes and Threads, 2024), użycie Mutex zamiast synchronized może zwiększyć wydajność o 30% przy wysokiej konkurencji.

Jak działa Mutex

Stany i operacje

Mutex znajduje się w jednym z dwóch stanów: zablokowany (locked) — przejęty przez wątek; wolny (unlocked) — nieprzejęty. Dwie podstawowe operacje to lock() (przejęcie) i unlock() (zwolnienie). Jeśli Mutex jest już przejęty, wątek wywołujący lock() zostaje zablokowany do momentu zwolnienia. W JVM zablokowany wątek przechodzi w stan BLOCKED i nie zużywa CPU.

Planowanie oczekujących wątków

Gdy Mutex zostaje zwolniony, system wybiera, który z oczekujących wątków otrzyma blokadę. Przy niesprawiedliwym (non-fair) planowaniu wybór może paść na wątek, który właśnie zwolnił muteks — zwiększa to przepustowość, ale może prowadzić do Starvation (głodzenia). Sprawiedliwy (fair) planista używa kolejki FIFO: pierwszy oczekujący wątek otrzymuje blokadę jako pierwszy. ReentrantLock(true) implementuje właśnie taki mechanizm.

Przejmowanie rekurencyjne (Reentrancy)

Większość implementacji Mutex w Java/Kotlin obsługuje rekurencyjne (reentrant) przejmowanie. Jeśli wątek już posiada Mutex i ponownie wywołuje lock(), operacja jest udana — Mutex nie blokuje samego siebie. Licznik rekurencji zwiększa się, a wątek musi wywołać unlock() tyle samo razy, co lock(). Jest to ważne dla wywołań rekurencyjnych i zagnieżdżonych sekcji krytycznych.

Przykład użycia Mutex w kodzie Kotlin

Rozważmy typowe zadanie — ochronę współdzielonego licznika przed Race Condition za pomocą ReentrantLock (klasyczny Mutex w Java/Kotlin). Bez Mutex kod dawałby nieprawidłowy wynik; z Mutex wszystkie 1000 wątków gwarantowanie zwiększa wartość licznika.

import java.util.concurrent.locks.ReentrantLock

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

    fun increment() {
        mutex.lock()
        try {
            count++  // sekcja krytyczna
        } finally {
            mutex.unlock()  // obowiązkowy 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())  // Zawsze 1000
}

Zwróć uwagę na blok finally — obowiązkowy wzorzec przy pracy z Mutex. Jeśli wewnątrz sekcji krytycznej wystąpi wyjątek, unlock() nie zostanie wywołany, a Mutex pozostanie zablokowany na zawsze — doprowadzi to do Deadlock. Blok finally gwarantuje zwolnienie Mutex przy każdym wyniku wykonania sekcji.

Alternatywne podejście w Kotlin — użycie funkcji rozszerzającej withLock, która automatycznie obsługuje lock/unlock z finally.

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

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

Mutex vs Semaphore vs Monitor

Te trzy mechanizmy synchronizacji są często mylone, choć mają różne właściwości i obszary zastosowań. Mutex — binarny, z własnością. Semaphore — licznik zezwoleń, bez własności. Monitor — mechanizm wysokiego poziomu łączący Mutex ze zmiennymi warunkowymi (condition variables). Zrozumienie różnic jest krytyczne dla wyboru odpowiedniego narzędzia do konkretnego zadania.

Kiedy wybrać Mutex: trzeba chronić jeden zasób przed jednoczesnym dostępem — na przykład współdzieloną kolekcję, plik lub licznik. Kiedy wybrać Semaphore — trzeba ograniczyć liczbę jednoczesnych dostępów do puli zasobów, na przykład pula połączeń z bazą danych na 5 połączeń. Kiedy wybrać Monitor — potrzebna jest synchronizacja z oczekiwaniem warunkowym, na przykład kolejka producer-consumer przez wait/notify. W nowoczesnym programowaniu Android często zastępuje się synchronized przez ReentrantLock lub kotlinx.coroutines Mutex.

Typowe błędy przy użyciu Mutex

Zapomniany unlock w finally

Najczęstszy błąd — brak bloku finally do wywołania unlock(). Jeśli w sekcji krytycznej wystąpi wyjątek, Mutex pozostaje zablokowany, a inne wątki czekają w nieskończoność. Nawet jeśli jesteś pewien, że wyjątki są niemożliwe — zawsze używaj try/finally lub withLock. To zasada defensive programming, szczególnie ważna w programowaniu mobilnym, gdzie wyjątki mogą wystąpić z powodu braku pamięci lub Configuration Changes.

Różna kolejność przejmowania Mutex

Gdy w aplikacji używanych jest wiele Mutex, krytyczne jest ustalenie jednolitej kolejności ich przejmowania. Jeśli Wątek A przejmuje M1 → M2, a Wątek B przejmuje M2 → M1, powstaje Deadlock. W dużych projektach (ponad 50 tysięcy linii kodu) kolejność blokad jest dokumentowana w decyzji architektonicznej i sprawdzana przez lintery. Narzędzie Lock Checker w IntelliJ IDEA automatycznie wykrywa niespójną kolejność przejmowania blokad.

Zbyt długa sekcja krytyczna

Utrzymywanie Mutex dłużej niż 1-2 milisekundy — oznaka nieprawidłowego projektu. Sekcja krytyczna powinna zawierać tylko minimalnie niezbędne operacje. Żądania sieciowe, wejście-wyjście plików i złożone obliczenia powinny być wykonywane poza zablokowanym blokiem. W Android długie utrzymywanie blokady w wątku UI prowadzi do pomijania klatek (jank) i ANR. Użyj ReadWriteLock, jeśli sekcja krytyczna składa się głównie z operacji odczytu.

Mutex w Kotlin Coroutines

Biblioteka kotlinx.coroutines udostępnia własną implementację Mutex, która fundamentalnie różni się od klasycznego ReentrantLock. Główna różnica — suspending Mutex nie blokuje wątku systemu operacyjnego, lecz zawiesza korutynę do momentu zwolnienia blokady. Oznacza to, że wątek może wykonywać inne korutyny, podczas gdy bieżąca oczekuje 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 — nie blokuje wątku
            count++
        }
    }

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

Kluczowe cechy kotlinx Mutex: nierekurencyjność (non-reentrant) — w przeciwieństwie do ReentrantLock, korutyna nie może ponownie przejąć Mutex, którym już włada. Jeśli jest to konieczne, użyj Semaphore(1) zamiast Mutex. Ponadto Mutex z kotlinx.coroutines jest nie-blokujący: używa zawieszania przez suspend, co pozwala nie blokować wątku puli.

W praktyce suspending Mutex jest preferowany nad klasycznym ReentrantLock w kodzie korutynowym z dwóch powodów: skalowanie — jedna korutyna oczekuje na Mutex, a wątek obsługuje inne korutyny, co zwiększa przepustowość systemu; brak BlockedThread — nie marnuje się zasobów na przechowywanie stosu zablokowanego wątku. Według JetBrains (Kotlin Coroutines Guide, 2024), użycie suspending Mutex zwiększa przepustowość o 40% przy 100+ korutynach.