Los turnstiles de Solaris siguen dentro de Go, WebKit y Rust

Solaris lleva más de una década sin ser un producto que nadie despliegue, pero uno de sus mecanismos de sincronización sigue funcionando dentro de software que se escribe hoy. Los turnstiles que Sun diseñó para sus mutex bloqueantes están detrás de las primitivas de espera del runtime de Go, del motor WebKit y del crate parking_lot de Rust. La idea de fondo es idéntica en los tres casos: sacar la coordinación de hilos a una estructura externa compartida y dejar los locks individuales lo más pequeños posible.

El problema: miles de locks diminutos

Solaris dependía de mutex bloqueantes para dar un comportamiento de baja latencia cercano al tiempo real, y eso traía dos complicaciones. La primera es de memoria: el bloqueo de grano fino exige miles de locks, y meter la contabilidad de cada cola de espera dentro del propio lock dispara el espacio que ocupa. La segunda es la inversión de prioridades, que ocurre cuando una tarea de prioridad alta se queda esperando un lock que sostiene otra de prioridad baja, y el trabajo de prioridad media la adelanta y deja al sistema parado.

La herencia de prioridades resuelve lo segundo, subiendo temporalmente la prioridad de quien tiene el lock, pero seguir las cadenas de dependencia sale caro. El turnstile lo plantea al revés: cuando un hilo se crea, ya tiene su propio turnstile asignado. Si se bloquea en un lock disputado, le dona ese turnstile, y el lock se localiza mediante una tabla hash global por cubos indexada por la dirección virtual del propio lock. Los locks sin contención quedan reducidos a un byte o una palabra.

El precio aparece con contención alta: se cambia el acceso a caché local por búsquedas en cubos globales, con más sincronización de bus y posibles cuellos de botella en el cubo compartido.

El mismo patrón en Go, WebKit y Rust

En Go no hay cola de espera dentro de cada mutex, canal o primitiva. El runtime resuelve los bloqueos con semáforos internos en sema.go: la dirección de la goroutine se pasa por hash hasta un cubo de la tabla global semtable y ahí se enlaza en un treap de estructuras sudog. El coste queda fuera del primitivo, que se mantiene ligero.

WebKit llegó al mismo sitio con WTF::ParkingLot, un mecanismo de aparcamiento en espacio de usuario. Los locks de WTF::Lock no cargan con el estado de un mutex ni de una variable de condición del sistema; cuando un hilo tiene que dormir, se aparca registrando su dirección en una tabla hash concurrente global.

Fuera de los navegadores y de los runtimes gestionados, el crate parking_lot de Rust porta explícitamente ese diseño de WebKit: una tabla hash externa de colas de espera indexada por la dirección del lock, con primitivas diminutas y unas características de rendimiento y equidad que superan a las del sistema operativo.

Que la arquitectura reaparezca en runtimes actuales dice bastante de dónde está la decisión al diseñar sincronización: no es qué lock usar, sino dónde vive el estado de espera. El resto del legado de Solaris —el asignador slab, ZFS, DTrace y las zonas— tuvo un recorrido parecido, casi siempre sin que nadie lo señalara.