Estado compartido: Mutex, confinamiento y actores

Todo lo anterior de este nivel evitaba el problema en lugar de resolverlo: si el estado vive dentro de una corrutina y los demás le hablan por un canal, no hay estado compartido y no hay nada que proteger. Pero hay sistemas donde esa reorganización no es viable o no es honesta, y entonces hay que enfrentarse a la pregunta directamente. La respuesta refleja —tomar un cerrojo— es la peor de las disponibles en un programa de corrutinas, y no por una cuestión de estilo: un cerrojo bloquea un hilo, y en un modelo donde miles de corrutinas comparten un puñado de hilos, bloquear uno es apagar una fracción medible de la máquina. Kotlin ofrece tres alternativas que no bloquean nada, y elegir entre ellas es una decisión de diseño con criterios objetivos.

Por qué bloquear es la respuesta equivocada

Un cerrojo clásico protege una sección crítica haciendo que el hilo que no puede entrar se detenga. Ese contrato tiene dos premisas que las corrutinas rompen. La primera es que el hilo es la unidad de ejecución: si detenerlo cuesta poco es porque hay muchos, y en un despachador con tantos hilos como núcleos, cuatro corrutinas bloqueadas pueden dejar el proceso entero parado aunque haya diez mil corrutinas listas para avanzar. La segunda es más profunda: un monitor pertenece al hilo que lo adquirió, y una corrutina puede cambiar de hilo en cada punto de suspensión, así que suspenderse dentro de una sección crítica significa reanudarse en un hilo que no posee el cerrojo.

Hay un tercer efecto que no se ve en el código y sí en las gráficas: los despachadores de la librería asumen que sus hilos no se detienen. Bloquear uno no solo resta capacidad, sino que puede provocar que trabajo perfectamente listo espere detrás de una barrera que el planificador no sabe que existe, porque para él ese hilo está ocupado ejecutando algo.

El compilador conoce ese peligro y lo rechaza: llamar a una función suspendida dentro de un bloque sincronizado produce el diagnóstico SUSPENSION_POINT_INSIDE_CRITICAL_SECTION. No es una advertencia de estilo, es la prevención de un fallo que sería intermitente e irreproducible.

// No compila: el punto de suspensión está dentro de la sección crítica.
synchronized(cerrojo) {
    val dato = repositorio.leer(id)   // función suspendida
    cache[id] = dato
}

Mutex: exclusión que suspende

Mutex es el equivalente que suspende en lugar de bloquear. Su uso normal es la función withLock, que adquiere, ejecuta y libera incluso ante excepciones o cancelación.

class Contador {
    private val mutex = Mutex()
    private var valor = 0

    suspend fun incrementar() = mutex.withLock { valor++ }

    suspend fun aplicar(id: String) = mutex.withLock {
        val dato = repositorio.leer(id)   // suspender aquí sí es legal
        valor += dato.peso
    }
}

Dos propiedades importan. La primera es la equidad: las corrutinas en espera se atienden en orden de llegada, lo que elimina la inanición pero también significa que la latencia del cerrojo crece con la contención de forma predecible y no aleatoria. La segunda es que no es reentrante: si una corrutina que ya posee el mutex intenta adquirirlo de nuevo, se queda esperando a sí misma para siempre, y el interbloqueo resultante no produce ningún error, solo una corrutina que nunca vuelve.

Hay también una variante no suspendida, tryLock, y un parámetro de propietario que permite detectar el intento de liberar un cerrojo que no se posee. Ambos son herramientas de nicho: el primero para caminos donde esperar no es aceptable, el segundo para depurar código donde la adquisición y la liberación están separadas, que es exactamente el código que withLock existe para que no escribas.

Esa omisión es deliberada. La reentrada exige saber quién posee el cerrojo, y en un mundo donde la unidad de ejecución es la corrutina y no el hilo, la identidad del poseedor no está disponible de forma barata ni bien definida. Pero hay un argumento de diseño mejor que el técnico: un cerrojo reentrante permite que una función pública protegida llame a otra función pública protegida, y eso convierte cualquier refactorización en una potencial ampliación silenciosa de la sección crítica. La regla que sobrevive es mantener las secciones críticas cortas, sin llamadas a código ajeno y sin invocar métodos públicos de la propia clase desde dentro.

Confinamiento por despachador

Existe una tercera vía que no protege el estado sino que impide que dos corrutinas lo toquen a la vez, obligándolas a ejecutarse en serie. La forma moderna de conseguirlo es pedir a un despachador una vista con paralelismo uno.

private val serie = Dispatchers.Default.limitedParallelism(1)
private var estado = Estado.inicial()

suspend fun mutar(accion: Accion) = withContext(serie) {
    estado = estado.aplicar(accion)   // nunca hay dos a la vez
}

La comparación con la alternativa histórica es instructiva. Durante años el idioma para esto fue crear un despachador de un solo hilo dedicado, que funciona pero reserva un hilo del sistema operativo para siempre y obliga a cerrarlo a mano, con lo que el estado gana un ciclo de vida propio que alguien tiene que administrar. El paralelismo limitado ofrece la misma serialización sin poseer ningún hilo, y por eso el constructor antiguo quedó marcado como obsoleto.

Conviene ser exacto sobre qué garantiza. No garantiza el mismo hilo: garantiza que no se ejecuten dos tareas simultáneamente, y por tanto no sirve para nada que dependa de variables locales al hilo. Lo que sí aporta, y es lo que importa, es que el propio acto de despachar establece la relación de precedencia necesaria para que lo que una tarea escribió sea visible para la siguiente. Y a diferencia de dedicar un hilo entero al estado, no inmoviliza ningún recurso: los hilos se toman prestados del despachador base solo mientras hay trabajo.

flowchart TD
A[Varias corrutinas tocan un estado] --> B[Cabe en una operacion atomica]
B -->|Si| C[Tipo atomico]
B -->|No| D[Hay suspension dentro de la seccion critica]
D -->|No y son muchas operaciones| E[Confinamiento con paralelismo uno]
D -->|Si| F[Mutex con withLock]
F --> G[El estado tiene protocolo y orden]
E --> G
G -->|Si| H[Actor sobre canal y mensajes sellados]

El actor y el criterio de elección

Un actor lleva la idea del confinamiento al extremo: el estado no se protege, se esconde dentro de una corrutina, y el resto del sistema solo puede enviarle mensajes por un canal. La exclusión mutua deja de existir como problema porque solo hay un ejecutor posible.

sealed interface Mensaje
data class Sumar(val n: Int) : Mensaje
data class Leer(val respuesta: CompletableDeferred<Int>) : Mensaje

fun CoroutineScope.contador(): SendChannel<Mensaje> {
    val buzon = Channel<Mensaje>(capacity = 64)
    launch {
        var valor = 0                       // estado privado de esta corrutina
        for (m in buzon) when (m) {
            is Sumar -> valor += m.n
            is Leer -> m.respuesta.complete(valor)
        }
    }
    return buzon
}

La forma del tipo de mensajes no es un detalle de implementación: es la interfaz pública del componente y el sitio donde queda registrado, de manera exhaustiva y verificable por el compilador, todo lo que se puede hacer con ese estado. Un actor bien escrito se lee entero mirando su tipo sellado, y añadir una operación obliga a completar el when, lo cual es una garantía que ninguna de las otras estrategias ofrece.

Ese código es todo el patrón: un canal, un bucle, un when exhaustivo y una variable local que nadie más puede ver. La librería tuvo un constructor actor dedicado que sigue existiendo marcado como obsoleto, y la recomendación oficial es exactamente lo de arriba, escrito a mano, porque compone mejor con la concurrencia estructurada y no oculta decisiones de ciclo de vida. Nótese además que el patrón de petición y respuesta necesita devolver un CompletableDeferred en el mensaje, y que la capacidad del buzón es la contrapresión del actor: si lo declaras ilimitado, has vuelto al problema de la primera lección.

El coste del actor tampoco hay que esconderlo. Cada operación pasa a ser un objeto asignado, un envío por canal y un cambio de corrutina, lo que lo descarta para estados que se tocan un millón de veces por segundo. Las lecturas dejan de ser gratuitas: consultar el valor exige un viaje de ida y vuelta, y si esa consulta es frecuente casi siempre conviene publicar el estado además en un StateFlow que el actor actualice, dejando el buzón únicamente para las escrituras. Y el orden, que es su gran virtud, es también una restricción: dos operaciones independientes que podrían ejecutarse a la vez no lo harán nunca, porque el actor tiene un solo hilo lógico de ejecución por diseño.