DispatchQueue en GCD: FIFO, prioridades QoS y ejecución en colas seriales o concurrentes

[GCD] DQ Concurrente: ejecución asíncrona

Esta es la combinación que produce paralelismo real en GCD: una cola concurrente despachando trabajo con async. El llamador no espera (por ser async) y las tareas pueden correr al mismo tiempo en hilos distintos (por ser la cola concurrente). Consideremos el siguiente fragmento de código, donde se despachan tres tareas con async sobre una cola concurrente: let concurrentQueue = DispatchQueue(label: "dev.goyes.concurrente", attributes: .concurrent) for i in 1...3 { concurrentQueue.async { print("Tarea \(i) empieza, hilo: \(Thread.current)") } } print("Las tres tareas ya se encolaron") A diferencia de la cola serial con async (donde el orden entre "Tarea 1", "Tarea 2" y "Tarea 3" sí estaba garantizado), aquí no hay ninguna garantía de orden entre esas tres líneas, ni entre ellas y "Las tres tareas ya se encolaron". El FIFO de la cola garantiza el orden en que GCD entrega las tres tareas para ejecución, pero una vez entregadas, cada una corre en un hilo independiente cuyo arranque real lo decide el scheduler del sistema operativo, no la cola. Reentrada: sigue siendo segura Igual que en la cola serial, llamar async desde un closure que ya está corriendo en la misma cola concurrente no produce deadlock. async nunca bloquea, así que solo agrega trabajo a la cola y continúa. Consideremos el siguiente fragmento de código, donde se llama async de forma anidada sobre la misma cola concurrente: let concurrentQueue = DispatchQueue(label: "dev.goyes.concurrente", attributes: .concurrent) concurrentQueue.async { print("Tarea externa") concurrentQueue.async { // Seguro, no hay deadlock print("Tarea interna") } } A diferencia de lo que podría parecer, "Tarea externa" sí está garantizado que se imprime completa antes de que "Tarea interna" pueda empezar, y eso no depende de que la cola sea serial o concurrente. La razón es orden de programa: print("Tarea externa") y la llamada anidada a async son dos líneas secuenciales dentro del mismo closure, ejecutadas una después de la otra en el mismo hilo. La llamada anidada ni siquiera somete "Tarea interna" a la cola hasta que print("Tarea externa") ya retornó, así que no hay ningún punto en el que ambas estén compitiendo por ejecutarse. La cola concurrente sí introduce una carrera real cuando varias tareas se someten de forma independiente, sin que una espere a que la otra termine de ejecutar su cuerpo completo: es el caso del ejemplo anterior con el for y las tres tareas async. El riesgo: nada serializa el acceso a estado compartido Combinar async con una cola concurrente, sobre estado mutable compartido, produce una carrera de datos si no hay ningún otro mecanismo de sincronización de por medio. Consideremos el siguiente fragmento de código, donde una clase UnsafeCounter incrementa un contador compartido desde una cola concurrente: final class UnsafeCounter { private let queue = DispatchQueue(label: "dev.goyes.counter", attributes: .concurrent) private var value = 0 func increment() { queue.async { self.value += 1 // ⚠️ Lectura + suma + escritura no es una operación atómica } } } Cada llamado a increment() retorna de inmediato y encola una escritura. Si varios hilos del pool concurrente ejecutan self.value += 1 al mismo tiempo, pueden leer el mismo valor antes de que el otro termine de escribir, y una de las dos sumas se pierde. Llamar increment() 100 veces desde distintos hilos no garantiza que value termine en 100. Esta es la situación exacta que DispatchBarrier y DispatchSemaphore existen para resolver, y que se cubre en los siguientes artículos. Lo que viene Falta ver DispatchWorkItem, una forma de empaquetar el trabajo que se despacha en un objeto en lugar de un closure suelto. Es útil cuando se necesita cancelar ese trabajo o esperar a que termine desde otro punto del código. Después de eso, DispatchGroup, DispatchBarrier y DispatchSemaphore cubren cómo coordinar y proteger trabajo concurrente como el de este artículo. Bibliografía async(execute:) (Apple Developer Documentation) DispatchQueue (Apple Developer Documentation) Concurrency Programming Guide (Apple)

2 hours ago

[GCD] Dispatch Queue: cola FIFO, prioridad y tipos de colas

Una DispatchQueue es el objeto al que se le envía trabajo en GCD. No se le envían hilos, se le envían closures (bloques de código), y es la cola la que decide cómo y cuándo ejecutarlas. FIFO: orden de inicio, no de finalización Una DispatchQueue es una cola FIFO (first in, first out): las tareas empiezan a ejecutarse en el orden en que se despacharon. Esto no implica que terminen en ese mismo orden — eso depende de si la cola es serial o concurrente (lo cual se cubre en los próximos dos artículos). Lo único garantizado por el FIFO es el orden de inicio. Prioridad: Quality of Service (QoS) Cada tarea que se despacha tiene una prioridad asociada, expresada como DispatchQoS. El sistema usa esa prioridad para decidir qué tarea atender primero cuando varias compiten por CPU: .userInteractive: la más alta. No significa "corre en main" ni "bloquea la interfaz" — el bloqueo de la UI solo ocurre si el trabajo corre en el hilo principal, y eso lo decide la cola, no el QoS. Es para trabajo cuya tardanza haría que la interfaz se sienta congelada (animaciones, o un cálculo en background cuyo resultado alimenta de inmediato a la UI). .userInitiated: trabajo que el usuario está esperando activamente (abrir un documento, procesar el resultado de un tap). .default: prioridad por defecto cuando no se especifica una explícita. .utility: trabajo de larga duración que no necesita resultado inmediato (descargas, procesamiento de datos, con barra de progreso visible). .background: la más baja. Trabajo que el usuario no percibe (sincronización en segundo plano, indexación). El QoS es una señal relativa de prioridad, no una garantía de velocidad. El scheduler del sistema la usa para decidir, cuando hay más hilos con trabajo pendiente que núcleos disponibles, a cuáles asignarles tiempo de CPU primero. Si todas las tareas del proceso declaran .userInteractive, el scheduler pierde la información que necesita para diferenciarlas: todas piden el mismo nivel de servicio, así que terminan repartiéndose los mismos núcleos por turnos (time-slicing), igual que pasaría si todas tuvieran .default. El resultado medible es que ninguna tarea termina antes por estar marcada .userInteractive — el código de animación que sí necesita esa prioridad ahora compite por CPU contra trabajo que no la necesitaba, con las mismas probabilidades de ser interrumpido. Tipos de cola GCD expone tres formas de obtener una DispatchQueue: // 1. Cola principal: serial, ligada al hilo principal (UI) let main = DispatchQueue.main // 2. Colas globales: concurrentes, provistas por el sistema, una por cada QoS let global = DispatchQueue.global(qos: .userInitiated) // 3. Cola propia: serial por defecto let custom = DispatchQueue(label: "com.miapp.tareas") // 3b. Cola propia, hecha concurrente explícitamente let customConcurrent = DispatchQueue(label: "com.miapp.tareas-concurrentes", attributes: .concurrent) Cola principal (DispatchQueue.main). Es serial y siempre ejecuta en el hilo principal. Todo lo que toca UI debe pasar por aquí. Colas globales (DispatchQueue.global(qos:)). Son concurrentes y las administra el sistema. No se crean, se obtienen — hay una por cada nivel de QoS, y se comparten con el resto de la app (y potencialmente con otros procesos del sistema). La firma es global(qos: DispatchQoS.QoSClass = .default): el parámetro tiene un valor por defecto, así que DispatchQueue.global() sin argumentos no significa "sin QoS" — equivale explícitamente a DispatchQueue.global(qos: .default). Colas propias (DispatchQueue(label:)). Las crea el desarrollador. Por defecto son seriales; se vuelven concurrentes solo si se especifica attributes: .concurrent. El label no afecta el comportamiento — sirve únicamente para identificar la cola en herramientas de depuración como Instruments. Nota: en el código de arriba, solo la cola global muestra explícitamente un QoS (qos: .userInitiated). No es que DispatchQueue.main y DispatchQueue(label:) carezcan de QoS — DispatchQueue.main corre siempre con la prioridad más alta del sistema y no se puede reconfigurar, y DispatchQueue(label:) sí acepta un parámetro qos: en su inicializador completo (init(label:qos:attributes:autoreleaseFrequency:target:)), simplemente no es necesario todavía para lo que cubre este artículo. Cómo asignar QoS a una cola propia se explica en un artículo posterior. Lo que viene Ya con cola serial vs. concurrente identificadas, lo que falta es ver cómo cambia el comportamiento al despachar trabajo de forma síncrona o asíncrona en cada una. Eso son los siguientes cuatro artículos. Bibliografía Apple Developer Documentation — DispatchQueue Apple Developer Documentation — DispatchQoS Apple — Concurrency Programming Guide

1 day ago