Mutex у мобилним апликацијама — шта је то, принцип рада и примена међусобног искључивања

Шта је Mutex?

Mutex (скраћеница од Mutual Exclusion — међусобно искључивање) — објекат синхронизације који управља приступом заједничком ресурсу у више nitnom okruženju. Када нит уђе у критичну секцију, преузима Mutex. Ако друга нит покуша да преузме исти Mutex, она прелази у стање чекања до ослобађања закључавања од стране прве нити.

Архитектура Mutex-а потиче из оперативног система THE, кога је развио Edsger Dijkstra 1965. године. Управо је Dijkstra увео концепт семафора, из којих се касније издвојио Mutex као посебан случај — бинарни семафор са подршком за власништво. Савремени оперативни системи (Linux, Windows, Android) имплементирају Mutex на нивоу језгра, што обезбеђује исправну синхронизацију чак и између различитих процеса.

Кључно својство Mutex-а је ownership (власништво). Само нит која је преузела мутекс може да га ослободи. Ово разликује Mutex од бинарног семафора, где било која нит може извршити сигнал (V-операцију). Власништво спречава случајно ослобађање закључавања од стране друге нити, што чини Mutex сигурнијим за типичне сценарије синхронизације у мобилном развоју. Према Android Developer Docs (Processes and Threads, 2024), употреба Mutex-а уместо synchronized може повећати перформансе за 30% при високој конкуренцији.

Како ради Mutex

Стања и операције

Mutex се налази у једном од два стања: закључан (locked) — преузет од стране нити; слободан (unlocked) — није преузет. Две основне операције — lock() (преузимање) и unlock() (ослобађање). Ако је Mutex већ преузет, нит која позива lock() се блокира до тренутка ослобађања. У JVM блокирана нит прелази у стање BLOCKED и не троши CPU.

Планирање нити у чекању

Када се Mutex ослободи, систем бира која од нити у чекању ће добити закључавање. Код неправедног (non-fair) планирања избор може пасти на нит која је управо ослободила мутекс — то повећава пропусну моћ, али може довести до Starvation (гладовања). Праведни (fair) планер користи FIFO ред: прва нит у чекању добија закључавање прва. ReentrantLock(true) имплементира управо такав механизам.

Рекурзивно преузимање (Reentrancy)

Већина имплементација Mutex-а у Java/Kotlin подржава рекурзивно (reentrant) преузимање. Ако нит већ поседује Mutex и поново позове lock(), операција је успешна — Mutex не блокира сам себе. Бројач рекурзије се повећава, и нит мора да позове unlock() онолико пута колико и lock(). Ово је важно за рекурзивне позиве и угњеждене критичне секције.

Пример употребе Mutex-а у коду на Kotlin-у

Размотримо типичан задатак — заштиту заједничког бројача од Race Condition помоћу ReentrantLock-а (класичан Mutex у Java/Kotlin). Без Mutex-а код би давао нетачан резултат; са Mutex-ом свих 1000 нити гарантовано повећава вредност бројача.

import java.util.concurrent.locks.ReentrantLock

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

    fun increment() {
        mutex.lock()
        try {
            count++  // критична секција
        } finally {
            mutex.unlock()  // обавезни 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())  // Увек 1000
}

Обратите пажњу на блок finally — обавезни образац при раду са Mutex-ом. Ако унутар критичне секције дође до изузетка, unlock() неће бити позван, и Mutex остаје закључан заувек — то доводи до Deadlock-а. Блок finally гарантује ослобађање Mutex-а при било ком исходу извршења секције.

Алтернативни приступ у Kotlin-у — употреба extension функције withLock, која аутоматски обрађује lock/unlock са finally.

fun increment() {
    mutex.withLock {  // lock + try/finally аутоматски
        count++
    }
}

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

Mutex vs Semaphore vs Monitor

Ова три механизма синхронизације се често мешају, иако имају различита својства и области примене. Mutex — бинарни, са власништвом. Semaphore — бројач дозвола, без власништва. Monitor — високоризиони механизам који обједињује Mutex са условним променљивим (condition variables). Разумевање разлика је критично за избор правог алата за одређени задатак.

Када изабрати Mutex: потребно је заштитити један ресурс од истовременог приступа — на пример, заједничку колекцију, датотеку или бројач. Када изабрати Semaphore — потребно је ограничити број истовремених приступа базену ресурса, на пример базен веза са базом података на 5 веза. Када изабрати Monitor — потребна је синхронизација са условним чекањем, на пример producer-consumer ред кроз wait/notify. У савременом Android развоју synchronized се често замењује ReentrantLock-ом или kotlinx.coroutines Mutex-ом.

Типичне грешке при коришћењу Mutex-а

Заборављени unlock у finally

Најчешћа грешка — одсуство finally блока за позив unlock(). Ако у критичној секцији дође до изузетка, Mutex остаје закључан, а друге нити чекају заувек. Чак и ако сте сигурни да су изузеци немогући — увек користите try/finally или withLock. Ово је принцип defensive programming, посебно важан у мобилном развоју, где изузеци могу настати због недостатка меморије или Configuration Changes.

Различит редослед преузимања Mutex-а

Када се у апликацији користи више Mutex-а, критично је успоставити јединствени редослед њиховог преузимања. Ако Nit A преузима M1 → M2, а Nit B преузима M2 → M1, настаје Deadlock. У великим пројектима (преко 50 хиљада линија кода) редослед закључавања се документује у архитектонској одлуци и проверава линтерима. Алат Lock Checker у IntelliJ IDEA аутоматски открива недоследан редослед преузимања закључавања.

Сувише дуга критична секција

Држање Mutex-а дуже од 1-2 милисекунде — знак неправилног дизајна. Критична секција треба да садржи само минимално неопходне операције. Мрежни захтеви, улазно-излазне операције са датотекама и сложена израчунавања треба да се извршавају ван блокираног блока. У Android-у дуго држање закључавања у UI нити доводи до испустања кадрова (jank) и ANR-а. Користите ReadWriteLock ако се критична секција углавном састоји од операција читања.

Mutex у Kotlin Coroutines

Библиотека kotlinx.coroutines пружа сопствену имплементацију Mutex-а која се фундаментално разликује од класичног ReentrantLock-а. Главна разлика — suspending Mutex не блокира нит оперативног система, већ суспендује corutinu до тренутка ослобађања закључавања. То значи да нит може извршавати друге corutine док тренутна чека на 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 — не блокира нит
            count++
        }
    }

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

Кључне карактеристике kotlinx Mutex-а: нерекурзивност (non-reentrant) — за разлику од ReentrantLock-а, corutina не може поново преузети Mutex којим већ влада. Ако је то потребно, користите Semaphore(1) уместо Mutex-а. Поред тога, Mutex из kotlinx.coroutines-а је неблокирајући: користи суспендовање кроз suspend, што омогућава да не блокира нит pool-a.

У пракси, suspending Mutex је пожељнији од класичног ReentrantLock-а у corutine коду из два разлога: скалирање — једна corutina чека на Mutex, а нит опслужује друге corutine, што повећава пропусну моћ система; одсуство BlockedThread — не троши се ресурс на чување стека блокиране нити. Према JetBrains (Kotlin Coroutines Guide, 2024), употреба suspending Mutex-а повећава пропусну моћ за 40% при 100+ corutina.