Mobil uygulamalarda Mutex — nedir, çalışma prensibi ve karşılıklı dışlamanın uygulanması

Mutex Nedir?

Mutex (Mutual Exclusion — karşılıklı dışlamanın kısaltması), çok thread'li bir ortamda paylaşılan bir kaynağa erişimi yöneten bir senkronizasyon nesnesidir. Bir thread kritik bölüme girdiğinde, Mutex'i alır. Başka bir thread aynı Mutex'i almaya çalışırsa, ilk thread kilidi serbest bırakana kadar bekleme durumuna alınır.

Mutex'in mimarisi, 1965 yılında Edsger Dijkstra tarafından tasarlanan THE işletim sistemine kadar uzanır. Dijkstra, semafor kavramını tanıttı ve daha sonra Mutex, özel bir durum olarak ortaya çıktı — sahiplik desteği olan ikili bir semafor. Modern işletim sistemleri (Linux, Windows, Android), Mutex'i çekirdek düzeyinde uygulayarak farklı süreçler arasında bile doğru senkronizasyonu garanti eder.

Mutex'in temel özelliği sahiplik (ownership)tir. Mutex'i alan thread yalnızca onu serbest bırakabilir. Bu, Mutex'i herhangi bir thread'in sinyal (V-işlemi) gerçekleştirebildiği ikili semafor'dan ayırır. Sahiplik, başka bir thread tarafından yanlışlıkla kilidin serbest bırakılmasını önler ve Mutex'i mobil geliştirmedeki tipik senkronizasyon senaryoları için daha güvenli hale getirir. Android Developer Docs'a (Processes and Threads, 2024) göre, yüksek rekabet altında synchronized yerine Mutex kullanmak performansı %30 oranında iyileştirebilir.

Mutex Nasıl Çalışır

Durumlar ve İşlemler

Mutex iki durumdan birindedir: kilitli (locked) — bir thread tarafından alınmış; veya serbest (unlocked) — alınmamış. İki temel işlem vardır: lock() (alma) ve unlock() (serbest bırakma). Mutex zaten kilitliyse, lock() çağıran thread kilit serbest kalana kadar bloke edilir. JVM'de, bloke edilen bir thread BLOCKED durumuna geçer ve CPU tüketmez.

Bekleyen Thread'lerin Zamanlaması

Bir Mutex serbest bırakıldığında, sistem hangi bekleyen thread'in kilidi alacağını seçer. Adil olmayan (non-fair) zamanlamada, seçim mutex'i yeni serbest bırakan thread'e düşebilir — bu verimi artırır ancak Açlığa (Starvation) yol açabilir. Adil (fair) zamanlayıcı bir FIFO kuyruğu kullanır: ilk bekleyen thread kilidi ilk alır. ReentrantLock(true) tam olarak bu mekanizmayı uygular.

Yinelenen Alma (Yeniden Girilebilirlik)

Java/Kotlin'deki çoğu Mutex uygulaması yeniden girilebilir (reentrant) almayı destekler. Bir thread zaten Mutex'e sahipse ve tekrar lock() çağırırsa, işlem başarılı olur — Mutex kendini bloke etmez. Yinelenme sayacı artar ve thread, lock() kadar unlock() çağırmalıdır. Bu, yinelenen çağrılar ve iç içe kritik bölümler için önemlidir.

Kotlin'de Mutex Kullanım Örneği

Tipik bir görevi ele alalım — ReentrantLock (Java/Kotlin'de klasik Mutex) kullanarak paylaşılan bir sayacı Race Condition'dan korumak. Mutex olmadan, kod yanlış sonuçlar üretir; Mutex ile, 1000 thread'in tümü sayacın değerini güvenilir bir şekilde artırır.

import java.util.concurrent.locks.ReentrantLock

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

    fun increment() {
        mutex.lock()
        try {
            count++  // kritik bölüm
        } finally {
            mutex.unlock()  // zorunlu 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())  // Her zaman 1000
}

finally bloğuna dikkat edin — Mutex ile çalışırken zorunlu bir desen. Kritik bölümde bir istisna oluşursa, unlock() çağrılmaz ve Mutex sonsuza kadar kilitli kalır — bu Deadlock'a yol açar. finally bloğu, bölümün yürütülmesi nasıl biterse bitsin Mutex'in serbest bırakılmasını garanti eder.

Kotlin'de alternatif bir yaklaşım, finally ile lock/unlock'u otomatik olarak işleyen withLock genişletme işlevini kullanmaktır.

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

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

Mutex vs Semafor vs Monitör

Bu üç senkronizasyon mekanizması sıklıkla karıştırılır, ancak farklı özelliklere ve kullanım durumlarına sahiptir. Mutex sahiplik ile ikilidir. Semafor, sahipliği olmayan bir izin sayacıdır. Monitör, Mutex'i koşul değişkenleriyle birleştiren üst düzey bir mekanizmadır. Farklılıkları anlamak, belirli bir görev için doğru aracı seçmek açısından kritik öneme sahiptir.

Mutex ne zaman seçilmeli: tek bir kaynağı eşzamanlı erişimden korumanız gerekiyorsa — örneğin, paylaşılan bir koleksiyon, dosya veya sayaç. Semafor ne zaman seçilmeli — bir kaynak havuzuna eşzamanlı erişim sayısını sınırlamanız gerekiyorsa, örneğin 5 bağlantılı bir veritabanı bağlantı havuzu. Monitör ne zaman seçilmeli — koşullu bekleme ile senkronizasyona ihtiyacınız varsa, örneğin wait/notify ile üretici-tüketici kuyruğu. Modern Android geliştirmede, synchronized genellikle ReentrantLock veya kotlinx.coroutines Mutex ile değiştirilir.

Mutex Kullanırken Sık Yapılan Hatalar

Finally'de unlock'u unutmak

En yaygın hata, unlock() çağırmak için finally bloğunun eksik olmasıdır. Kritik bölümde bir istisna oluşursa, Mutex kilitli kalır ve diğer thread'ler sonsuza kadar bekler. İstisnaların imkansız olduğundan emin olsanız bile — her zaman try/finally veya withLock kullanın. Bu, savunmacı programlama ilkesidir ve bellek yetersizliği veya Configuration Changes nedeniyle istisnaların ortaya çıkabileceği mobil geliştirmede özellikle önemlidir.

Farklı Mutex Alma Sırası

Bir uygulama birden çok Mutex kullandığında, tutarlı bir alma sırası oluşturmak kritik öneme sahiptir. Thread A, M1 → M2'yi alırsa ve Thread B, M2 → M1'i alırsa, Deadlock oluşur. Büyük projelerde (50 bin satırdan fazla kod), kilit sırası mimari kararda belgelenir ve lint araçları tarafından doğrulanır. IntelliJ IDEA'daki Lock Checker aracı, tutarsız kilit alma sırasını otomatik olarak algılar.

Kritik Bölüm Çok Uzun

Bir Mutex'i 1-2 milisaniyeden uzun tutmak, kötü tasarımın işaretidir. Kritik bölüm yalnızca minimum gerekli işlemleri içermelidir. Ağ istekleri, dosya G/Ç ve karmaşık hesaplamalar kilitli blok dışında gerçekleştirilmelidir. Android'de, UI thread'inde uzun süreli kilit tutma, kare düşüşlerine (jank) ve ANR'ye yol açar. Kritik bölüm esas olarak okuma işlemlerinden oluşuyorsa ReadWriteLock kullanın.

Kotlin Coroutines'de Mutex

kotlinx.coroutines kütüphanesi, klasik ReentrantLock'tan temel olarak farklı olan kendi Mutex uygulamasını sağlar. Temel fark, suspending Mutex'in OS thread'ini bloke etmemesi, ancak kilit serbest kalana kadar coroutine'i askıya almasıdır. Bu, mevcut coroutine Mutex'i beklerken thread'in diğer coroutine'leri çalıştırabileceği anlamına gelir.

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 — thread'i bloke etmez
            count++
        }
    }

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

kotlinx Mutex'in temel özellikleri: yeniden girilemez (non-reentrant) — ReentrantLock'tan farklı olarak, bir coroutine zaten sahip olduğu bir Mutex'i tekrar alamaz. Bu gerekliyse, Mutex yerine Semaphore(1) kullanın. Ayrıca, kotlinx.coroutines'in Mutex'i bloke etmez: havuz thread'ini bloke etmemek için suspend ile askıya almayı kullanır.

Pratikte, coroutine kodunda suspending Mutex'in klasik ReentrantLock'a tercih edilmesinin iki nedeni vardır: ölçeklenebilirlik — bir coroutine Mutex'i beklerken thread diğer coroutine'lere hizmet verir, sistem verimini artırır; BlockedThread yok — bloke edilen thread'in yığınını depolamak için kaynak harcanmaz. JetBrains'e (Kotlin Coroutines Guide, 2024) göre, 100+ coroutine ile suspending Mutex kullanmak verimi %40 artırır.