Thread safety en Swift: ¿GCD con barreras, OSAllocatedUnfairLock o actors?

🔒 Garantizar seguridad entre hilos es uno de los retos más complejos en desarrollo iOS. Un simple diccionario compartido puede provocar condiciones de carrera, crashes o estados corruptos si varios hilos escriben y leen simultáneamente sin la sincronización adecuada.⚙️ La solución clásica con GCD usa colas concurrentes con lecturas síncronas y escrituras asíncronas. Pero sin el flag .barrier, las lecturas y escrituras pueden solaparse, creando inconsistencias. El patrón recomendado es lecturas concurrentes y escrituras serializadas mediante barriers.🚀 OSAllocatedUnfairLock llega en iOS 16 como el wrapper moderno de os_unfair_lock. Gestiona memoria automáticamente, es Sendable, y su API withLock elimina el riesgo de olvidar liberar el lock. Usa la misma primitiva del kernel que su predecesor pero sin interoperabilidad con C.🛡️ Los actores de Swift Concurrency eliminan colas y barreras por completo. Aislan el estado mutable garantizando que solo una tarea pueda acceder a él simultáneamente. El compilador y el runtime manejan la sincronización sin bloqueos explícitos ni riesgo de deadlocks.🔬 Internamente, los actors gestionan una cola de tareas pendientes y un flag para indicar si están activos. Cuando una tarea llama a un método del actor, Swift la encola. El actor procesa su cola secuencialmente, ejecutando una tarea a la vez, lo que garantiza aislamiento total del estado.⚡ Si priorizas rendimiento y seguridad con GCD, usa .barrier. Para compatibilidad total con Swift 6 y simplificar tu código, los actores son el camino. Apple recomienda migrar de os_unfair_lock a OSAllocatedUnfairLock para garantizar comportamiento correcto del locking.👨‍💻 ¿Ya estás usando actores en tus proyectos o sigues confiando en GCD? La evolución del ecosistema Swift apunta claramente hacia concurrencia estructurada y la seguridad de datos por defecto.