Mutex en aplicaciones móviles — qué es, principio de funcionamiento y aplicación de la exclusión mutua

¿Qué es Mutex?

Mutex (abreviatura de Mutual Exclusion — exclusión mutua) es un objeto de sincronización que gestiona el acceso a un recurso compartido en un entorno multihilo. Cuando un hilo entra en una sección crítica, adquiere el Mutex. Si otro hilo intenta adquirir el mismo Mutex, se pone en estado de espera hasta que el primer hilo libere el bloqueo.

La arquitectura de Mutex se remonta al sistema operativo THE, diseñado por Edsger Dijkstra en 1965. Dijkstra introdujo el concepto de semáforos, de los cuales Mutex surgió más tarde como un caso especial — un semáforo binario con soporte de propiedad. Los SO modernos (Linux, Windows, Android) implementan Mutex a nivel de kernel, lo que garantiza una sincronización correcta incluso entre diferentes procesos.

La propiedad clave de Mutex es la propiedad (ownership). Solo el hilo que adquirió el mutex puede liberarlo. Esto distingue a Mutex de un semáforo binario, donde cualquier hilo puede realizar una señal (operación V). La propiedad evita la liberación accidental del bloqueo por otro hilo, haciendo que Mutex sea más seguro para escenarios típicos de sincronización en desarrollo móvil. Según Android Developer Docs (Processes and Threads, 2024), usar Mutex en lugar de synchronized puede mejorar el rendimiento en un 30% bajo alta contención.

Cómo funciona Mutex

Estados y operaciones

Un Mutex se encuentra en uno de dos estados: bloqueado (locked) — adquirido por un hilo; o libre (unlocked) — no adquirido. Hay dos operaciones básicas: lock() (adquirir) y unlock() (liberar). Si el Mutex ya está bloqueado, el hilo que llama a lock() se bloquea hasta que se libere el bloqueo. En la JVM, un hilo bloqueado pasa al estado BLOCKED y no consume CPU.

Planificación de hilos en espera

Cuando se libera un Mutex, el sistema selecciona qué hilo en espera recibe el bloqueo. Con planificación no justa (non-fair), la elección puede recaer en el hilo que acaba de liberar el mutex — esto aumenta el rendimiento pero puede provocar inanición (Starvation). Un planificador justo (fair) utiliza una cola FIFO: el primer hilo en espera recibe el bloqueo primero. ReentrantLock(true) implementa exactamente este mecanismo.

Adquisición recursiva (Reentrancia)

La mayoría de las implementaciones de Mutex en Java/Kotlin admiten la adquisición reentrante. Si un hilo ya posee el Mutex y vuelve a llamar a lock(), la operación tiene éxito — Mutex no se bloquea a sí mismo. El contador de recursión aumenta, y el hilo debe llamar a unlock() tantas veces como a lock(). Esto es importante para llamadas recursivas y secciones críticas anidadas.

Ejemplo de uso de Mutex en código Kotlin

Consideremos una tarea típica — proteger un contador compartido de condiciones de carrera usando ReentrantLock (Mutex clásico en Java/Kotlin). Sin Mutex, el código daría resultados incorrectos; con Mutex, los 1000 hilos incrementan de forma fiable el valor del contador.

import java.util.concurrent.locks.ReentrantLock

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

    fun increment() {
        mutex.lock()
        try {
            count++  // sección crítica
        } finally {
            mutex.unlock()  // finally obligatorio
        }
    }

    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())  // Siempre 1000
}

Presta atención al bloque finally — un patrón obligatorio al trabajar con Mutex. Si ocurre una excepción dentro de la sección crítica, unlock() no se llamará y el Mutex quedará bloqueado para siempre — esto provoca un Deadlock. El bloque finally garantiza la liberación del Mutex independientemente de cómo termine la ejecución de la sección.

Un enfoque alternativo en Kotlin es usar la función de extensión withLock, que maneja automáticamente lock/unlock con finally.

fun increment() {
    mutex.withLock {  // lock + try/finally automáticamente
        count++
    }
}

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

Mutex vs Semáforo vs Monitor

Estos tres mecanismos de sincronización a menudo se confunden, aunque tienen diferentes propiedades y casos de uso. Mutex es binario con propiedad. El Semáforo es un contador de permisos sin propiedad. El Monitor es un mecanismo de alto nivel que combina Mutex con variables de condición. Comprender las diferencias es críticamente importante para elegir la herramienta adecuada para una tarea específica.

Cuándo elegir Mutex: necesitas proteger un solo recurso del acceso concurrente — por ejemplo, una colección compartida, un archivo o un contador. Cuándo elegir Semáforo — necesitas limitar el número de accesos concurrentes a un grupo de recursos, como un grupo de conexiones de base de datos con 5 conexiones. Cuándo elegir Monitor — necesitas sincronización con espera condicional, como una cola productor-consumidor mediante wait/notify. En el desarrollo moderno de Android, synchronized a menudo se reemplaza por ReentrantLock o kotlinx.coroutines Mutex.

Errores comunes al usar Mutex

Olvidar unlock en finally

El error más común es omitir el bloque finally para llamar a unlock(). Si ocurre una excepción en la sección crítica, el Mutex permanece bloqueado y otros hilos esperan para siempre. Incluso si estás seguro de que las excepciones son imposibles — usa siempre try/finally o withLock. Este es un principio de programación defensiva, especialmente importante en el desarrollo móvil donde las excepciones pueden surgir por falta de memoria o Configuration Changes.

Orden diferente de adquisición de Mutex

Cuando una aplicación utiliza varios Mutex, es críticamente importante establecer un orden de adquisición consistente. Si el Hilo A adquiere M1 → M2, y el Hilo B adquiere M2 → M1, se produce un Deadlock. En proyectos grandes (más de 50 mil líneas de código), el orden de bloqueo se documenta en la decisión arquitectónica y se verifica con linters. La herramienta Lock Checker en IntelliJ IDEA detecta automáticamente el orden inconsistente de adquisición de bloqueos.

Sección crítica demasiado larga

Mantener un Mutex durante más de 1-2 milisegundos es señal de un diseño incorrecto. La sección crítica debe contener solo las operaciones mínimas necesarias. Las solicitudes de red, la E/S de archivos y los cálculos complejos deben realizarse fuera del bloque bloqueado. En Android, mantener un bloqueo prolongadamente en el hilo de la UI provoca pérdida de fotogramas (jank) y ANR. Usa ReadWriteLock si la sección crítica consiste principalmente en operaciones de lectura.

Mutex en Kotlin Coroutines

La biblioteca kotlinx.coroutines proporciona su propia implementación de Mutex, que difiere fundamentalmente del ReentrantLock clásico. La principal diferencia es que suspending Mutex no bloquea el hilo del SO, sino que suspende la corrutina hasta que se libere el bloqueo. Esto significa que el hilo puede ejecutar otras corrutinas mientras la actual espera el 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 — no bloquea el hilo
            count++
        }
    }

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

Características clave de kotlinx Mutex: no reentrante — a diferencia de ReentrantLock, una corrutina no puede readquirir un Mutex que ya posee. Si esto es necesario, usa Semaphore(1) en lugar de Mutex. Además, Mutex de kotlinx.coroutines no es bloqueante: utiliza la suspensión mediante suspend, lo que permite no bloquear el hilo del pool.

En la práctica, suspending Mutex es preferible al ReentrantLock clásico en código de corrutinas por dos razones: escalabilidad — una corrutina espera el Mutex mientras el hilo atiende otras corrutinas, aumentando el rendimiento del sistema; sin BlockedThread — no se gasta recurso en almacenar la pila del hilo bloqueado. Según JetBrains (Kotlin Coroutines Guide, 2024), usar suspending Mutex mejora el rendimiento en un 40% con 100+ corrutinas.