RwLock: muchos lectores o un solo escritor

Mutex<T> trata todo acceso por igual: leer y escribir compiten por el mismo turno único, aunque dos lecturas nunca podrían pisarse. Para muchas cargas eso es desperdicio: una tabla de configuración que mil hilos consultan y uno actualiza cada minuto no debería serializar las mil lecturas. RwLock<T> —lector/escritor— afina la exclusión distinguiendo dos modos: read() admite muchos lectores simultáneos, porque la lectura concurrente es inofensiva; write() exige exclusividad total, ni un lector más. Si te suena, es porque es exactamente la regla del borrow checker —muchos & o un solo &mut— pero comprobada en ejecución y a través de fronteras de hilo. Donde el compilador demuestra esa ley estáticamente para las referencias, RwLock la impone dinámicamente para el estado compartido.

Dos guards, dos permisos

RwLock<T> ofrece dos formas de entrar, cada una con su tipo de guard:

use std::sync::{Arc, RwLock};
use std::thread;

fn main() {
    let config = Arc::new(RwLock::new(String::from("v1")));

    let mut lectores = Vec::new();
    for id in 0..4 {
        let config = Arc::clone(&config);
        lectores.push(thread::spawn(move || {
            let actual = config.read().unwrap();     // guard COMPARTIDO
            println!("lector {id} ve {}", *actual);
        }));                                          // varios pueden coexistir
    }

    {
        let mut w = config.write().unwrap();          // guard EXCLUSIVO
        *w = String::from("v2");                      // espera a que no quede ningun lector
    }

    for l in lectores {
        l.join().unwrap();
    }
}

• read() devuelve un RwLockReadGuard, que solo hace Deref a &T. Puedes tener muchos vivos a la vez en distintos hilos; ninguno molesta a los otros porque nadie muta.
• write() devuelve un RwLockWriteGuard, que hace DerefMut a &mut T. Solo puede existir uno, y mientras vive no hay ningún lector. Si al pedir write() hay lectores activos, el hilo espera a que todos suelten su guard.

Igual que en Mutex, ambos métodos devuelven LockResult —de ahí el .unwrap()— y ambos guards liberan por RAII al salir de scope. La diferencia entera está en la cardinalidad: read es “de muchos”, write es “de uno y excluyente”.

flowchart TD
R[read pide acceso compartido] --> RM[Muchos RwLockReadGuard a la vez]
W[write pide acceso exclusivo] --> WM[Un solo RwLockWriteGuard y cero lectores]
RM --> LEY[Misma ley del borrow checker en ejecucion]
WM --> LEY
LEY --> N[Muchos and inmutables o un and mutable jamas ambos]
style R fill:#a6e3a1,color:#11111b
style W fill:#f38ba8,color:#11111b
style LEY fill:#cba6f7,color:#11111b
style N fill:#89b4fa,color:#11111b

Cuándo conviene sobre Mutex, y cuándo no

RwLock no es “un Mutex mejor”: es un Mutex con una apuesta distinta. Cambiar uno por otro solo compensa si el patrón de acceso encaja.

La intuición: RwLock mantiene más estado interno para contar lectores y coordinar la exclusión del escritor, así que cada operación cuesta un poco más que en un Mutex. Solo recuperas esa inversión si de verdad hay lectores concurrentes que se solapan y ese solapamiento ahorra tiempo. Para secciones críticas diminutas o cargas equilibradas, la respuesta por defecto sigue siendo Mutex; y para un simple contador o bandera, un tipo atómico (AtomicU64, AtomicBool) evita el candado por completo.

Un patrón real: caché de lectura intensiva

El caso que justifica un RwLock es la caché que casi todos consultan y casi nadie actualiza: una tabla de sesiones, un mapa de precios, una configuración caliente. Muchos hilos leen a la vez sin estorbarse, y solo la rara actualización pide exclusividad.

use std::sync::{Arc, RwLock};
use std::collections::HashMap;

type Cache = Arc<RwLock<HashMap<String, u64>>>;

fn consultar(cache: &Cache, clave: &str) -> Option<u64> {
    let mapa = cache.read().unwrap();       // lectura concurrente
    mapa.get(clave).copied()
}

fn actualizar(cache: &Cache, clave: String, valor: u64) {
    let mut mapa = cache.write().unwrap();  // exclusiva y breve
    mapa.insert(clave, valor);
}

Aquí RwLock rinde porque consultar se llama miles de veces por cada actualizar, y todas esas consultas corren en paralelo. Fíjate en la disciplina de siempre: cada guard vive lo mínimo —una expresión— para no retener el candado ni un instante de más. Si el reparto fuera al revés, con escrituras constantes, este mismo código con Mutex sería más simple y probablemente más rápido. La elección del candado es, literalmente, una hipótesis sobre la proporción entre lecturas y escrituras.