DEV Community: GoyesDev

[GCD] Problemas de GCD

GoyesDev — Wed, 01 Jul 2026 22:07:25 +0000

GCD resolvió el problema que motivó toda esta serie de artículos: administrar hilos a mano es peligroso y difícil de acertar. Pero GCD trae sus propios problemas, que no desaparecen solo por usar colas en lugar de hilos directamente. Este artículo repasa siete de ellos.

Complejidad conceptual: hilo y cola son dos cosas distintas

Trabajar con GCD obliga a razonar sobre dos conceptos al mismo tiempo: la cola a la que se despacha trabajo, y el hilo en el que ese trabajo termina corriendo. No son lo mismo, y la relación entre ambos no siempre es obvia. Hace falta tener en cuenta, para cada tarea despachada:

Si la cola es serial o concurrente (cambia si hay garantía de exclusión mutua).
Si se despacha con sync o async (cambia si el llamador espera, y en qué hilo puede terminar reutilizándose el trabajo).
Qué QoS tiene la tarea (cambia con qué prioridad compite por CPU).
Si el código ya está corriendo en esa misma cola (una llamada sync reentrante produce un deadlock, cubierto en el artículo sobre DQ Serial: ejecución síncrona).

Ese modelo mental hay que reconstruirlo en cada punto del código donde se despacha trabajo. Un error tan simple como llamar DispatchQueue.main.sync desde código que ya corre en el hilo principal, sin darse cuenta de en qué cola se está parado, produce un deadlock silencioso que no aparece hasta que el código corre.

Completion handlers anidados

Cuando una operación asíncrona depende del resultado de otra, y esa a su vez de otra, el código con closures de finalización se anida cada vez más hacia la derecha.

El siguiente fragmento encadena tres operaciones asíncronas, cada una dentro del closure de finalización de la anterior:

func fetchUser(id: Int, completion: @escaping (User?) -> Void) { /* ... */ }
func fetchPosts(for user: User, completion: @escaping ([Post]?) -> Void) { /* ... */ }
func fetchComments(for post: Post, completion: @escaping ([Comment]?) -> Void) { /* ... */ }

fetchUser(id: 1) { user in
  guard let user = user else { return }
  fetchPosts(for: user) { posts in
    guard let firstPost = posts?.first else { return }
    fetchComments(for: firstPost) { comments in
      print(comments ?? [])
    }
  }
}

Con tres pasos ya es notorio. Con cinco o seis (una secuencia de llamadas de red real no es rara que llegue ahí), el código se vuelve difícil de leer en orden: cada nivel de indentación introduce su propio alcance, sus propias variables capturadas, y su propio punto de retorno anticipado.

Manejo de errores doloroso

Los closures de finalización no tienen una forma estándar de propagar errores hacia arriba, como sí la tiene throws/catch. Cada nivel de anidamiento tiene que manejar su propio error por separado, normalmente repitiendo el mismo patrón una y otra vez.

Retomando el fragmento anterior, con manejo de errores explícito en cada nivel:

func fetchUser(id: Int, completion: @escaping (Result<User, Error>) -> Void) { /* ... */ }
func fetchPosts(for user: User, completion: @escaping (Result<[Post], Error>) -> Void) { /* ... */ }
func fetchComments(for post: Post, completion: @escaping (Result<[Comment], Error>) -> Void) { /* ... */ }

fetchUser(id: 1) { userResult in
  switch userResult {
  case .failure(let error):
    print("Error obteniendo el usuario: \(error)")
  case .success(let user):
    fetchPosts(for: user) { postsResult in
      switch postsResult {
      case .failure(let error):
        print("Error obteniendo los posts: \(error)")
      case .success(let posts):
        guard let firstPost = posts.first else { return }
        fetchComments(for: firstPost) { commentsResult in
          switch commentsResult {
          case .failure(let error):
            print("Error obteniendo los comentarios: \(error)")
          case .success(let comments):
            print(comments)
          }
        }
      }
    }
  }
}

No hay ningún mecanismo del lenguaje que junte los tres switch en un solo punto de manejo de errores. Cada nivel repite la misma estructura, y olvidar un caso en cualquiera de ellos compila sin advertencia.

Propenso a olvidar llamar el closure de callback

El compilador no obliga a que un closure de finalización se llame en todos los caminos posibles de una función. Si una rama del código retorna sin invocar el completion, el código que llamó a esa función se queda esperando una respuesta que nunca llega, sin ningún error ni advertencia.

Este otro fragmento ilustra una función con una rama que olvida llamar a completion:

func fetchValue(completion: @escaping (Int?) -> Void) {
  guard someCondition else {
    return // ⚠️ Nunca se llama completion(): quien llame a fetchValue() espera para siempre
  }
  completion(42)
}

Este es el mismo tipo de bug, en esencia, que olvidar group.leave() en DispatchGroup (cubierto en el artículo sobre DispatchGroup): el código compila perfectamente, y el problema solo se manifiesta en tiempo de ejecución, como un colgado que puede ser difícil de reproducir si someCondition casi siempre es verdadera.

Carrera de datos sin protección del compilador

El compilador de Swift no impide compilar código como el de UnsafeCounter (artículo sobre DQ Concurrente: ejecución asíncrona), donde varias tareas modifican el mismo estado desde hilos distintos sin ninguna sincronización. GCD no tiene ningún mecanismo propio que detecte esto en tiempo de compilación: hace falta usar herramientas externas, como el Thread Sanitizer de Xcode, para encontrar estas carreras, y solo detectan las que efectivamente ocurren durante una ejecución concreta, no todas las que son posibles.

Explosión de threads

El pool de hilos que GCD administra para las colas concurrentes tiene un límite práctico, típicamente alrededor de 64 hilos por proceso para el pool por defecto. Cada tarea que se bloquea (con sync, con wait() de un DispatchGroup o un DispatchSemaphore, o durmiendo un hilo) sigue contando como un hilo ocupado desde la perspectiva del sistema operativo, aunque no esté haciendo trabajo útil. Si se despachan muchas tareas que se bloquean unas a otras sobre colas globales, GCD puede llegar a crear un hilo nuevo por cada una hasta agotar ese límite, y quedarse sin hilos disponibles para la tarea de la que las demás dependían. El resultado es indistinguible de un deadlock desde el punto de vista del usuario, aunque técnicamente el sistema sigue "funcionando": simplemente ya no tiene con qué avanzar.

Este riesgo crece con patrones ya vistos en este módulo, como despachar una tarea bloqueante (sync, wait()) dentro de otra tarea que ya está corriendo en una cola concurrente compartida: cada nivel de anidamiento consume un hilo más del pool mientras espera. La forma de evitarlo es limitar cuántas colas concurrentes propias existen en la app y evitar bloquear hilos del pool global innecesariamente.

Inversión de prioridad

Una tarea de prioridad alta puede terminar esperando por un recurso (un lock, un semáforo) que en ese momento tiene tomado una tarea de prioridad baja. Si el scheduler del sistema le da tiempo de CPU preferentemente a tareas de prioridad alta o media, y ninguna de esas tareas es la que tiene el recurso tomado, la tarea de baja prioridad que sí lo tiene puede tardar en recibir tiempo de CPU para terminar y liberarlo. El resultado es que la tarea de prioridad alta, a pesar de su prioridad, termina esperando indefinidamente por una tarea de prioridad baja que ni siquiera está compitiendo directamente con ella.

Lo que viene

Estos siete problemas (más los ya cubiertos en artículos anteriores, como la ambigüedad entre orden de entrega y orden real de inicio) son la motivación para buscar herramientas de más alto nivel para expresar concurrencia, algo que queda fuera del alcance de este módulo sobre GCD.

Bibliografía

[GCD] Sincronización de hilos con DispatchSemaphore

GoyesDev — Wed, 01 Jul 2026 21:49:17 +0000

DispatchBarrier resuelve el acceso exclusivo (una sola tarea a la vez) sobre una cola concurrente. DispatchSemaphore generaliza esa idea: en lugar de limitar el acceso a una sola tarea, limita el acceso a un número arbitrario de tareas simultáneas, y no depende de ninguna cola en particular. También sirve, igual que DispatchGroup, para convertir una API basada en callbacks en código que bloquea hasta obtener un resultado.

Qué es un semáforo: wait() y signal()

Un DispatchSemaphore se crea con un contador inicial: DispatchSemaphore(value:). Ese contador representa cuántos accesos simultáneos están permitidos.

El siguiente fragmento crea un semáforo con un contador inicial de 1:

let semaphore = DispatchSemaphore(value: 1)

wait() decrementa el contador. Si el resultado sigue siendo mayor o igual a cero, wait() retorna de inmediato. Si el contador ya estaba en cero, wait() bloquea el hilo que hace el llamado hasta que otro hilo llame signal(), que incrementa el contador y, si hay algún hilo bloqueado en wait(), lo despierta.

Limitar cuántas tareas acceden a un recurso al mismo tiempo

Un semáforo con contador inicial N permite que hasta N tareas corran a la vez, y bloquea a las demás hasta que alguna de las N termine y llame signal().

El fragmento de abajo despacha cinco tareas sobre una cola concurrente, pero limita a dos el número de tareas que pueden correr al mismo tiempo:

let semaphore = DispatchSemaphore(value: 2)
let queue = DispatchQueue(label: "dev.goyes.gcd.semaphore", attributes: .concurrent)
let group = DispatchGroup()

for i in 1...5 {
  group.enter()
  queue.async {
    semaphore.wait()
    print("Tarea \(i) empieza")
    Thread.sleep(forTimeInterval: 0.3)
    print("Tarea \(i) termina")
    semaphore.signal()
    group.leave()
  }
}

group.wait()

Aunque las cinco tareas se despachan de inmediato, solo dos pueden pasar de semaphore.wait() a la vez. Las otras tres quedan bloqueadas en wait() hasta que alguna de las dos primeras llame signal(). DispatchGroup aquí solo sirve para que el código de prueba espere a que las cinco tareas terminen, no forma parte del límite de concurrencia: eso lo impone el semáforo.

Semáforo con contador 1: el mismo efecto que una barrera, sin cola dedicada

Con contador inicial 1, un semáforo se comporta como un lock clásico: como máximo una tarea a la vez puede estar entre wait() y signal().

Este otro fragmento protege un contador compartido con un semáforo de contador 1, en lugar de usar DispatchBarrier:

final class SafeCounter {
  private let semaphore = DispatchSemaphore(value: 1)
  private var value = 0

  func increment() {
    semaphore.wait()
    value += 1
    semaphore.signal()
  }

  func currentValue() -> Int {
    semaphore.wait()
    defer { semaphore.signal() }
    return value
  }
}

La diferencia con DispatchBarrier es que un semáforo no necesita una cola concurrente propia ni ninguna cola en particular: wait() y signal() funcionan sin importar desde qué hilo o cola se llamen. A cambio, a diferencia de DispatchBarrier (que sigue permitiendo lecturas en paralelo mientras no haya una escritura de por medio), un semáforo con contador 1 serializa absolutamente todo acceso, tanto lecturas como escrituras, sin distinción.

Convertir una API con callback en código que bloquea

Igual que DispatchGroup, un semáforo permite esperar de forma bloqueante a que termine un trabajo asíncrono con su propio closure de finalización, pero sin necesidad de enter()/leave(): basta con inicializar el semáforo en 0.

Considérese la siguiente función, que simula una API asíncrona con su propio closure de finalización:

func fetchRemoteValue(completion: @escaping (Int) -> Void) {
  DispatchQueue.global().asyncAfter(deadline: .now() + 0.3) {
    completion(42)
  }
}

El siguiente fragmento usa un semáforo, inicializado en 0, para bloquear hasta que fetchRemoteValue entregue su resultado:

let semaphore = DispatchSemaphore(value: 0)
var result: Int?

fetchRemoteValue { value in
  result = value
  semaphore.signal()
}

semaphore.wait()
print(result!) // 42

Con contador inicial 0, la primera llamada a wait() siempre bloquea, porque no hay ningún acceso disponible todavía. Solo se desbloquea cuando fetchRemoteValue termina y su closure de finalización llama signal().

wait() en el hilo principal bloquea la interfaz

Aunque parezca un detalle menor, wait() bloquea el hilo que hace el llamado exactamente igual que sync. Si ese hilo es el principal, la interfaz se congela mientras dura el bloqueo: no se procesan eventos de UI, no hay animaciones, la app deja de responder. Esto aplica sin importar cuán rápido se espere que el semáforo se libere: si fetchRemoteValue tarda 300 milisegundos en el ejemplo anterior y ese semaphore.wait() se llama desde el hilo principal, la interfaz queda congelada esos 300 milisegundos. En un caso real, donde la tarea que se espera es una llamada de red con latencia variable, ese bloqueo puede ser mucho más largo e impredecible. Por eso wait() nunca debería llamarse desde el hilo principal cuando exista alguna posibilidad de que tarde en desbloquearse.

Diferencia con DispatchGroup: signal() de más no falla de inmediato

DispatchGroup exige un balance estricto entre enter() y leave(): llamar leave() de más produce un crash inmediato. Un semáforo es más permisivo: llamar signal() sin un wait() correspondiente no falla en ese momento, solo deja el contador por encima de su valor inicial, disponible para que futuros wait() no bloqueen. El riesgo aparece más adelante: si el semáforo se libera de memoria mientras su contador no coincide con el valor inicial, libdispatch sí detecta ese estado inconsistente y termina la app con un crash (BUG IN CLIENT OF LIBDISPATCH: Semaphore object deallocated while in use).

El riesgo opuesto sigue siendo igual de real que con DispatchGroup: si se llama wait() más veces de las que se llama signal(), el hilo que hace el llamado se queda bloqueado para siempre.

let semaphore = DispatchSemaphore(value: 0)
semaphore.wait() // ⚠️ Nunca se llama semaphore.signal(): este wait() se queda bloqueado para siempre

Lo que viene

Falta ver, juntando todo lo que se cubrió en este módulo, los problemas más comunes que aparecen al trabajar con GCD y cómo reconocerlos. Eso es lo que cubre el siguiente artículo.

Bibliografía

[GCD] Sincronización de hilos con DispatchBarrier

GoyesDev — Wed, 01 Jul 2026 21:24:54 +0000

En el artículo sobre DQ Concurrente: ejecución síncrona quedó pendiente un problema: en una cola concurrente, sync no implica exclusión mutua. Una lectura despachada con sync puede correr al mismo tiempo, en un hilo distinto, que una escritura despachada con async, porque nada en la cola serializa el acceso entre tareas independientes. DispatchBarrier resuelve exactamente ese problema, sin renunciar del todo al paralelismo de una cola concurrente.

Qué hace una barrera

Una tarea despachada con la bandera .barrier sobre una cola concurrente se ejecuta con exclusión mutua: mientras corre, ninguna otra tarea de esa misma cola corre en paralelo con ella. Además, todas las tareas despachadas antes de la barrera tienen que terminar antes de que la barrera empiece, y todas las tareas despachadas después tienen que esperar a que la barrera termine. Efectivamente, la cola se comporta como serial mientras la barrera está en ejecución, y vuelve a comportarse como concurrente en cuanto termina.

Cómo despachar una tarea con .barrier

Tanto sync como async aceptan la bandera .barrier a través del parámetro flags:.

El siguiente fragmento despacha una tarea con async(flags: .barrier) sobre una cola concurrente:

let queue = DispatchQueue(label: "dev.goyes.gcd.barrier", attributes: .concurrent)

queue.async(flags: .barrier) {
  print("Corriendo en exclusión mutua respecto al resto de la cola")
}

No tiene sentido aplicar .barrier sobre una cola serial: una cola serial ya ejecuta una tarea a la vez, así que la exclusión mutua que ofrece la barrera ya existe de por sí.

Orden garantizado alrededor de la barrera

El fragmento de abajo despacha dos tareas normales, luego una con .barrier, y luego una tarea normal más, todas sobre la misma cola concurrente:

let queue = DispatchQueue(label: "dev.goyes.gcd.barrier-order", attributes: .concurrent)
var result: [Int] = []
let group = DispatchGroup()

for i in 1...2 {
  group.enter()
  queue.async {
    Thread.sleep(forTimeInterval: 0.3)
    result.append(i)
    group.leave()
  }
}

group.enter()
queue.async(flags: .barrier) {
  result.append(3)
  group.leave()
}

group.enter()
queue.async {
  Thread.sleep(forTimeInterval: 0.1)
  result.append(4)
  group.leave()
}

group.wait()

// result empieza con 1 y 2 en algún orden, sigue con 3, y termina con 4

El orden entre 1 y 2 no está garantizado entre sí (son dos tareas normales corriendo en paralelo), pero ambas terminan antes de que 3 (la barrera) pueda empezar. 4, despachada después de la barrera, no corre hasta que 3 termina, así que siempre queda al final.

Usar una barrera para proteger lecturas y escrituras

El fragmento siguiente retoma la clase UnsafeCache del artículo sobre DQ Concurrente: ejecución síncrona, protegida ahora con una barrera en la escritura:

final class Cache {
  private let queue = DispatchQueue(label: "dev.goyes.cache-barrier", attributes: .concurrent)
  private var storage: [String: Data] = [:]

  func write(_ value: Data, forKey key: String) {
    queue.async(flags: .barrier) {
      self.storage[key] = value
    }
  }

  func read(forKey key: String) -> Data? {
    queue.sync {
      storage[key]
    }
  }
}

read sigue despachando con sync, sin ninguna bandera especial: varias lecturas pueden seguir corriendo en paralelo entre sí, porque leer no modifica storage. write despacha con async(flags: .barrier): mientras una escritura está en curso, ninguna lectura ni ninguna otra escritura corre al mismo tiempo, así que ya no hay forma de leer un valor a medias ni de perder una escritura por una carrera de datos. Comparado con la versión completamente serial del primer Cache (dos artículos atrás), esta sigue permitiendo que varias lecturas corran en paralelo cuando no hay ninguna escritura de por medio, algo que la versión serial no podía ofrecer.

Cuándo no usar una barrera

Una barrera no debería aplicarse sobre una cola global (DispatchQueue.global(qos:)). Las colas globales las administra el sistema y las comparte todo el proceso (y potencialmente otros procesos), así que despachar una barrera ahí bloquea trabajo de otras partes de la app que no tienen ninguna relación con lo que la barrera protege. Para usar una barrera, lo correcto es crear una cola concurrente propia, dedicada al recurso que se quiere proteger, como en el ejemplo de Cache.

Lo que viene

Falta ver DispatchSemaphore, otra herramienta para limitar cuántas tareas acceden a un recurso al mismo tiempo, mostrado en un artículo posterior.

Bibliografía

[GCD] Sincronización implícita y explícita con DispatchGroup

GoyesDev — Wed, 01 Jul 2026 21:13:18 +0000

En artículos anteriores ya apareció DispatchGroup, pero solo como herramienta auxiliar para que el código de prueba esperara a que terminara trabajo despachado con async. Este artículo lo cubre como tema central: cómo coordinar varias tareas independientes y ejecutar algo (o desbloquear un hilo) solo cuando todas hayan terminado, sin importar el orden en que terminen ni en qué cola corran.

Marcar entrada y salida de forma explícita: enter(), leave() y notify(queue:execute:)

group.enter() marca que una tarea empezó, y group.leave() marca que terminó. enter() se llama antes de despachar la tarea; leave() se llama dentro del closure despachado, en el punto donde el trabajo realmente termina.

Consideremos el siguiente fragmento de código, donde tres tareas se despachan con async sobre una cola concurrente, cada una marcando su propio enter()/leave():

let group = DispatchGroup()
let queue = DispatchQueue(label: "dev.goyes.gcd.group", attributes: .concurrent)
var result: [Int] = []

for i in 1...3 {
  group.enter()
  queue.async {
    Thread.sleep(forTimeInterval: 0.3)
    result.append(i)
    group.leave()
  }
}

group.notify(queue: .main) {
  print("Todas las tareas terminaron: \(result)")
}

notify(queue:execute:) registra un closure que se ejecuta, en la cola indicada, cuando el número de leave() recibidos iguala al número de enter() registrados. No bloquea ningún hilo: el closure se encola automáticamente cuando el grupo se vacía. El orden en que las tres tareas terminan y anotan su valor en result no está garantizado (la cola es concurrente), pero notify solo corre después de que las tres, sin importar el orden, ya hayan llamado leave().

Error común: llamar enter() dentro del bloque async

enter() tiene que ejecutarse en el hilo que despacha la tarea, antes de queue.async, no dentro del closure que se despacha. Moverlo adentro es un error frecuente porque el código compila y parece razonable, pero rompe la sincronización.

El siguiente fragmento repite el ejemplo anterior, con ese error introducido:

let group = DispatchGroup()
let queue = DispatchQueue(label: "dev.goyes.gcd.group-bug", attributes: .concurrent)
var result: [Int] = []

for i in 1...3 {
  queue.async {
    group.enter() // ⚠️ Debería llamarse antes de queue.async, no dentro
    Thread.sleep(forTimeInterval: 0.3)
    result.append(i)
    group.leave()
  }
}

group.notify(queue: .main) {
  print("Todas terminaron: \(result)") // Puede imprimir "[]", sin haber esperado a ninguna
}

group.notify se llama justo después del for, en el hilo que hace el llamado, y en ese momento ninguna de las tres tareas ha alcanzado a ejecutar su enter() todavía (recién se despacharon, corren en otro hilo). Desde la perspectiva del grupo, en ese instante no hay ningún enter() pendiente: el conteo está en cero. notify considera que el grupo ya está vacío y programa su closure para correr de inmediato, sin haber esperado a que ninguna tarea real termine.

Forma implícita: async(group:execute:)

En lugar de enter()/leave() manuales, async(group:execute:) los maneja de forma implícita: enter() ocurre justo antes de que el closure empiece a correr, y leave() ocurre justo cuando ese mismo closure retorna.

Cuando todo el trabajo de la tarea es código síncrono contenido por completo dentro del closure (sin llamadas asíncronas anidadas), esa forma implícita es segura y funciona exactamente igual que la forma explícita.

El siguiente fragmento reemplaza el enter()/leave() manual del primer ejemplo por la forma implícita, sin cambiar el comportamiento:

let group = DispatchGroup()
let queue = DispatchQueue(label: "dev.goyes.gcd.group-implicit-safe", attributes: .concurrent)
var result: [Int] = []

for i in 1...3 {
  queue.async(group: group) {
    Thread.sleep(forTimeInterval: 0.3)
    result.append(i)
  }
}

group.notify(queue: .main) {
  print("Todas las tareas terminaron: \(result)")
}

Cada closure hace todo su trabajo (Thread.sleep y result.append(i)) antes de retornar, así que el leave() implícito ocurre exactamente en el punto donde la tarea realmente termina. group.notify sigue esperando correctamente a las tres.

El riesgo de async(group:execute:): callbacks anidados

leave() se dispara cuando el closure retorna, no cuando el trabajo que ese closure representa termina de verdad. Para saber si async(group:execute:) es seguro en un caso concreto, hay que revisar si el código que va dentro del closure tiene, a su vez, algún bloque de callback propio (una llamada de red, un temporizador, cualquier API que reciba un closure de finalización). Si lo tiene, ese callback interno es el verdadero punto donde el trabajo termina, y ahí es donde debería ir leave(), no al final del closure exterior. Por eso leave() no siempre va en la última línea del bloque: cuando hay un callback anidado, leave() tiene que pasarse dentro de ese callback, y eso obliga a usar la forma explícita.

Tomemos como ejemplo una función que simula una llamada asíncrona con su propio closure de finalización:

func fetchRemoteValue(completion: @escaping (Int) -> Void) {
  DispatchQueue.global().asyncAfter(deadline: .now() + 0.3) {
    completion(42)
  }
}

El siguiente fragmento usa async(group:execute:) con esta función, de forma incorrecta:

let group = DispatchGroup()
let queue = DispatchQueue(label: "dev.goyes.gcd.group-implicit-wrong")
var result: Int?

queue.async(group: group) {
  fetchRemoteValue { value in
    result = value // ⚠️ El closure exterior ya retornó y leave() ya se llamó antes de que esto corra
  }
}

group.notify(queue: .main) {
  print("result: \(String(describing: result))") // Puede imprimir "nil"
}

El closure exterior retorna de inmediato después de llamar a fetchRemoteValue, porque fetchRemoteValue en sí también retorna de inmediato (solo agenda el trabajo real). async(group:execute:) marca leave() en ese momento, antes de que el closure de finalización (completion) siquiera haya corrido. La forma correcta es usar enter()/leave() explícitos, con leave() dentro del callback real:

let group = DispatchGroup()
let queue = DispatchQueue(label: "dev.goyes.gcd.group-implicit-correct")
var result: Int?

group.enter()
queue.async {
  fetchRemoteValue { value in
    result = value
    group.leave() // El callback es el verdadero punto de finalización del trabajo
  }
}

group.notify(queue: .main) {
  print("result: \(String(describing: result))") // Siempre tiene el valor 42
}

Sincronización bloqueante con wait()

Además de notify, que no bloquea nada, wait() bloquea el hilo que hace el llamado hasta que el grupo se vacía por completo.

El fragmento de abajo despacha tres tareas sobre una cola concurrente y usa wait() para bloquear hasta que las tres hayan terminado:

let group = DispatchGroup()
let queue = DispatchQueue(label: "dev.goyes.gcd.group-wait", attributes: .concurrent)
var result: [Int] = []

for i in 1...3 {
  group.enter()
  queue.async {
    Thread.sleep(forTimeInterval: 0.3)
    result.append(i)
    group.leave()
  }
}

group.wait()
print("Todas terminaron: \(result)")

print("Todas terminaron: \(result)") solo se ejecuta después de que wait() retorna, y wait() no retorna hasta que las tres tareas ya llamaron leave(). Es la misma relación que existe entre sync y async al despachar una sola tarea: notify es la versión no bloqueante, wait() es la versión bloqueante.

Balance estricto entre enter() y leave()

Cada enter() tiene que tener su leave() correspondiente, ni más ni menos. Los dos desbalances posibles fallan de formas distintas, como muestran los siguientes dos fragmentos.

Más leave() que enter()

Si se llama leave() más veces que enter(), el conteo interno del grupo baja por debajo de su valor inicial, lo cual es un error fatal detectado por libdispatch en tiempo de ejecución: la app termina con un crash del tipo BUG IN CLIENT OF LIBDISPATCH: Unbalanced call to dispatch_group_leave().

El siguiente fragmento provoca ese crash llamando leave() una vez de más:

let group = DispatchGroup()

group.enter()
group.leave()
group.leave() // ⚠️ Crash: BUG IN CLIENT OF LIBDISPATCH: Unbalanced call to dispatch_group_leave()

Más enter() que leave(): el grupo nunca se vacía

Si se llama enter() más veces que leave(), el grupo nunca llega a un conteo de cero. wait() se queda bloqueado para siempre y el closure de notify nunca se ejecuta.

Este otro fragmento ilustra ese caso, con una tarea que nunca llama a leave():

group.enter()
queue.async {
  // ⚠️ Si esta tarea nunca llama a group.leave(), wait() y notify() se quedan esperando para siempre
}

Lo que viene

Falta ver cómo proteger el acceso a estado compartido en una cola concurrente sin serializar también las lecturas, con DispatchBarrier. Eso es lo que cubre el siguiente artículo.

Bibliografía

[GCD] Cancelando un DispatchWorkItem

GoyesDev — Wed, 01 Jul 2026 20:35:56 +0000

Un DispatchWorkItem se puede cancelar con cancel(), pero la cancelación es cooperativa, no preventiva: cancel() no interrumpe código que ya está corriendo. Lo que hace depende de en qué momento se llama, antes de que el trabajo empiece a correr o mientras ya está corriendo.

Cancelar antes de que empiece a correr

Si cancel() se llama antes de que el DispatchWorkItem empiece a ejecutarse, el bloque nunca llega a correr. GCD comprueba el estado de cancelación justo antes de invocar el bloque y, si ya está cancelado, se lo salta por completo.

Consideremos el siguiente fragmento de código, donde se cancela un DispatchWorkItem antes de despacharlo:

let queue = DispatchQueue(label: "dev.goyes.gcd.workitem-cancel")
let workItem = DispatchWorkItem {
  print("Este mensaje nunca se imprime")
}

workItem.cancel()
queue.async(execute: workItem)

No importa que después se despache con queue.async(execute: workItem): como ya estaba cancelado antes de eso, el closure nunca se ejecuta.

Cancelar mientras ya está corriendo: cancelación cooperativa

Si cancel() se llama después de que el bloque ya empezó a correr, no lo detiene. Lo único que hace es marcar isCancelled como true. Detener el trabajo depende del bloque mismo: tiene que revisar isCancelled en algún punto de su propia ejecución y decidir terminar antes de tiempo.

El siguiente fragmento muestra un DispatchWorkItem que ejecuta un bucle y revisa isCancelled en cada iteración:

var workItem: DispatchWorkItem?

workItem = DispatchWorkItem {
  for i in 1...5 {
    if workItem?.isCancelled == true {
      print("Cancelado, deteniendo en la iteración \(i)")
      break
    }
    print("Iteración \(i)")
    Thread.sleep(forTimeInterval: 0.5)
  }
}

let queue = DispatchQueue(label: "dev.goyes.gcd.workitem-cancel")
queue.async(execute: workItem!)

Thread.sleep(forTimeInterval: 1.2)
workItem?.cancel()
workItem?.wait()

workItem se declara como una variable opcional separada, en lugar de asignarse directamente al resultado de DispatchWorkItem { ... }, porque el bloque necesita referenciar la variable workItem para leer isCancelled, y esa variable todavía no existe mientras se está construyendo el closure. Al llamar cancel() después de 1.2 segundos, el bucle ya alcanzó a correr varias iteraciones (cada una tarda 0.5 segundos). isCancelled pasa a true en ese momento, pero la iteración que está en curso no se interrumpe: el bloque solo se entera y se detiene la próxima vez que su código revisa la propiedad, al principio de la siguiente iteración.

Si el bloque nunca revisara isCancelled, cancel() marcaría la propiedad de todos modos, pero el bucle completaría sus 5 iteraciones sin que nada lo detuviera.

wait() sigue funcionando igual con un DispatchWorkItem cancelado

cancel() no afecta el comportamiento de wait() ni de notify(queue:execute:). Si el trabajo se cancela antes de correr, wait() retorna de inmediato porque no hay nada que ejecutar. Si se cancela mientras corre, wait() sigue bloqueando hasta que el bloque termine por su cuenta.

Lo que viene

Falta ver cómo coordinar varias tareas que corren en paralelo y esperar a que todas terminen, con DispatchGroup. Eso es lo que cubre el siguiente artículo.

Bibliografía

[GCD] Trabajando con DispatchWorkItem

GoyesDev — Wed, 01 Jul 2026 20:20:47 +0000

Hasta ahora, el trabajo despachado a una DispatchQueue ha sido siempre un closure suelto: queue.async { ... }. Un DispatchWorkItem envuelve ese mismo bloque de código en un objeto, en lugar de pasarlo directamente. La diferencia práctica es que un closure suelto se pierde en el momento en que se despacha (no hay forma de referenciarlo después), mientras que un DispatchWorkItem se puede guardar en una variable y usar para esperar su finalización, recibir una notificación cuando termine, o cancelarlo con cancel(), tanto antes de que empiece a correr como mientras ya está corriendo (esto último se cubre en el artículo siguiente).

Creando y despachando un DispatchWorkItem

Consideremos el siguiente fragmento de código, donde se crea un DispatchWorkItem y se despacha con async, igual que se haría con un closure suelto:

let queue = DispatchQueue(label: "dev.goyes.gcd.workitem")
let workItem = DispatchWorkItem {
  print("Trabajo ejecutándose")
}

queue.async(execute: workItem)

queue.async(execute:) y queue.sync(execute:) aceptan un DispatchWorkItem igual que aceptan un closure. Las reglas de sync vs. async y de cola serial vs. concurrente cubiertas en los artículos anteriores aplican exactamente igual: lo único que cambia es que ahora hay un objeto al que se puede volver después de despacharlo.

Ejecutarlo directamente con perform()

Un DispatchWorkItem no necesita una cola para correr. perform() ejecuta el bloque de forma síncrona, en el hilo que hace el llamado, sin pasar por ninguna cola.

Consideremos el siguiente fragmento de código, donde se llama perform() directamente:

let workItem = DispatchWorkItem {
  print("Corriendo en el hilo: \(Thread.current)")
}

workItem.perform()
// Corre de inmediato, en el mismo hilo que llama a perform(). Equivale a invocar el closure directamente.

Esperar su finalización con wait()

wait() bloquea el hilo que hace el llamado hasta que el DispatchWorkItem termine de ejecutarse, sin importar en qué cola se haya despachado ni si se usó sync o async para despacharlo.

Consideremos el siguiente fragmento de código, donde se despacha un DispatchWorkItem con async y luego se espera su finalización por separado:

let queue = DispatchQueue(label: "dev.goyes.gcd.workitem")
let workItem = DispatchWorkItem {
  Thread.sleep(forTimeInterval: 1)
  print("Trabajo terminado")
}

queue.async(execute: workItem)
print("Despachado, sin esperar todavía")

workItem.wait()
print("Ahora sí terminó, un segundo después")

wait() es útil precisamente porque se llama en un punto distinto al del despacho: el código puede seguir haciendo otras cosas entre queue.async(execute: workItem) y workItem.wait(), algo que no es posible con queue.sync, que bloquea de inmediato en el mismo punto donde se despacha.

Recibir una notificación al terminar con notify(queue:execute:)

En lugar de bloquear un hilo con wait(), notify(queue:execute:) registra un closure que se ejecuta automáticamente, en la cola indicada, cuando el DispatchWorkItem termina.

Consideremos el siguiente fragmento de código, donde se registra una notificación antes de despachar el trabajo:

let queue = DispatchQueue(label: "dev.goyes.gcd.workitem")
let workItem = DispatchWorkItem {
  Thread.sleep(forTimeInterval: 1)
  print("Trabajo terminado")
}

workItem.notify(queue: .main) {
  print("Notificación: el trabajo ya terminó, en el hilo principal")
}

queue.async(execute: workItem)

notify no bloquea ningún hilo: el closure de notificación se encola en .main (o en la cola que se indique) automáticamente cuando el trabajo termina, sin que nada tenga que esperar activamente por él.

Lo que viene

Un DispatchWorkItem también se puede cancelar con cancel(), tanto antes de que empiece a correr (en ese caso nunca llega a ejecutarse) como mientras ya está corriendo (en ese caso queda marcado como cancelado en isCancelled, pero el bloque debe revisar esa propiedad y detenerse por sí mismo). Eso es lo que cubre el siguiente artículo.

Bibliografía

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

GoyesDev — Wed, 01 Jul 2026 20:02:27 +0000

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.

Veamos qué pasa al llamar 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.

El siguiente fragmento muestra una clase UnsafeCounter que 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.

El siguiente fragmento llama increment() 100 veces desde distintos hilos y luego lee el valor final a través de currentValue(), un método que despacha la lectura con sync sobre la misma cola para evitar leer a mitad de una escritura:

let counter = UnsafeCounter()
let group = DispatchGroup()

for _ in 1...100 {
  group.enter()
  DispatchQueue.global().async {
    counter.increment()
    group.leave()
  }
}

group.wait()
print(counter.currentValue()) // No garantiza imprimir 100

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

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

GoyesDev — Tue, 30 Jun 2026 23:29:32 +0000

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

La API es la misma que en una cola serial: sync bloquea al llamador hasta que el closure despachado termina. Lo que cambia es qué hace la cola con el resto de su trabajo mientras tanto.

Consideremos el siguiente fragmento de código, donde se despacha un bloque con sync sobre una cola concurrente:

let concurrentQueue = DispatchQueue(label: "dev.goyes.gcd.concurrent", attributes: .concurrent)
var result: [Int] = []

result.append(1)

concurrentQueue.sync {
  Thread.sleep(forTimeInterval: 1)
  result.append(2)
}

result.append(3)

// result == [1, 2, 3]

Para una sola tarea despachada con sync, el comportamiento observado es idéntico al de una cola serial: el llamador espera, y el orden queda garantizado: result termina en [1, 2, 3], nunca en otro orden. La diferencia aparece cuando hay más tareas además de la que se está esperando.

`sync` bloquea por esa tarea, no por la cola

En una cola concurrente, varias tareas pueden estar corriendo en hilos distintos al mismo tiempo. sync bloquea al llamador hasta que su tarea termine. No detiene ni espera a las demás tareas que la cola esté procesando en paralelo.

El siguiente fragmento despacha tres tareas con async y luego una más con sync sobre la misma 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)")
    Thread.sleep(forTimeInterval: 1)
    print("Tarea \(i) termina")
  }
}

concurrentQueue.sync {
  print("Tarea de sincronización")
}

Las tres tareas despachadas con async se despachan, en orden de código, antes que la "Tarea de sincronización". El sync final espera a que su propio closure termine, pero no espera a que las tres tareas anteriores terminen. Esas siguen corriendo en paralelo, en sus propios hilos, independientemente de lo que haga el llamador.

El orden de entrega FIFO no garantiza el orden real de inicio

Al correr exactamente este código, una salida real fue:

Tarea de sincronización
Tarea 2 empieza, hilo: <NSThread: 0x104b29bc0>{number = 7, name = (null)}
Tarea 3 empieza, hilo: <NSThread: 0x1048e06c0>{number = 3, name = (null)}
Tarea 1 empieza, hilo: <NSThread: 0x1048e0b80>{number = 5, name = (null)}

"Tarea de sincronización", despachada después de las tres, imprimió primero. Y entre las tres tareas async, el orden tampoco fue 1, 2, 3, sino 2, 3, 1.

Esto no contradice el FIFO de la cola: el FIFO garantiza el orden en que GCD entrega los closures para ejecución, no el orden real en que cada hilo ejecuta su primera instrucción. Una vez entregado un closure a un hilo, es el scheduler del sistema operativo quien decide cuándo ese hilo corre, no GCD. Y sync, a diferencia de async, puede reutilizar el hilo que hace el llamado en lugar de pedir uno nuevo al pool concurrente: no tiene que pagar el costo de adquisición de un hilo nuevo, que sí pagan las tres tareas despachadas con async. Por eso terminó primero pese a haberse despachado después.

Esa ventaja no garantiza que `sync` siempre termine primero

Reutilizar el hilo invocador solo elimina el costo de adquisición de un hilo nuevo. No dice nada sobre cuánto tarda el propio trabajo del bloque. Si el bloque despachado con sync hace más trabajo que las tareas async, termina después de ellas, sin importar que se haya ahorrado ese costo de adquisición.

A continuación se modifica el ejemplo anterior: el bloque de sync ahora duerme dos segundos antes de imprimir, mientras las tres tareas async conservan su segundo de espera:

let concurrentQueue = DispatchQueue(label: "dev.goyes.concurrente", attributes: .concurrent)

for i in 1...3 {
  concurrentQueue.async {
    print("Tarea \(i) empieza")
    Thread.sleep(forTimeInterval: 1)
    print("Tarea \(i) termina")
  }
}

concurrentQueue.sync {
  Thread.sleep(forTimeInterval: 2)
  print("Tarea de sincronización")
}

Al correr exactamente este código, una salida real fue:

Tarea 1 empieza
Tarea 2 empieza
Tarea 3 empieza
Tarea 1 termina
Tarea 2 termina
Tarea 3 termina
Tarea de sincronización

El orden entre las tres tareas async puede variar entre ejecuciones, como ya se mostró arriba. Lo que no varía es que las tres terminan, empiezan y terminan, antes que la tarea de sincronización imprima su línea.

El orden de entrega FIFO sigue siendo el mismo: las tres tareas async se entregan antes que el bloque sync, sin excepción. Lo que cambió frente al ejemplo anterior es cuánto tarda cada tarea en completar su propio trabajo una vez que arranca: cada async duerme un segundo, mientras que sync duerme dos. La ventaja de reutilizar el hilo invocador evita el costo de adquisición, pero no compensa una diferencia de un segundo completo en el trabajo del bloque.

Esto muestra que la ventaja de sync sobre async es evitar un costo de arranque, no una garantía de terminar primero. sync termina primero solo cuando, sumando ese ahorro más el tiempo de su propio trabajo, sigue siendo más rápido que las alternativas. Si su trabajo tarda más, pierde esa carrera, sin importar que haya arrancado con ventaja.

Encadenar varios `sync` sí produce orden determinista

Si en lugar de mezclar sync con tareas async independientes se despachan varias llamadas sync seguidas sobre la misma cola concurrente, el resultado es tan predecible como en una cola serial: cada sync bloquea por completo antes de que el código siga a la siguiente línea, así que nunca hay dos llamados sync compitiendo entre sí por arrancar.

Este otro fragmento encadena tres llamadas sync seguidas sobre una cola concurrente:

let concurrentQueue = DispatchQueue(label: "dev.goyes.gcd.concurrent", attributes: .concurrent)
var result: [Int] = []

result.append(1)

for i in 2...4 {
  concurrentQueue.sync {
    Thread.sleep(forTimeInterval: 1)
    result.append(i)
  }
}

result.append(5)

// result == [1, 2, 3, 4, 5]

Esto no contradice lo mostrado arriba: la falta de garantía de orden real de inicio aparece cuando varias tareas se despachan de forma independiente y pueden competir por arrancar en paralelo. Aquí no hay competencia posible, porque el código nunca llega a despachar la siguiente tarea hasta que la anterior ya terminó. Que la cola sea concurrente es irrelevante para este patrón de uso específico.

El riesgo: `sync` no implica exclusión mutua

Como una cola concurrente no serializa el acceso, usar sync para leer un recurso no protege contra una escritura que se esté ejecutando en paralelo en otro hilo de la misma cola.

El fragmento de abajo muestra una clase UnsafeCache que usa una cola concurrente sin ningún mecanismo adicional de sincronización:

final class UnsafeCache {
  private let queue = DispatchQueue(label: "dev.goyes.cache-concurrente", attributes: .concurrent)
  private var storage: [String: Data] = [:]

  func write(_ value: Data, forKey key: String) {
    queue.async {
      self.storage[key] = value // ⚠️ Puede correr al mismo tiempo que una lectura
    }
  }

  func read(forKey key: String) -> Data? {
    queue.sync {
      storage[key]
    }
  }
}

A diferencia del Cache con cola serial del artículo anterior, aquí read y write pueden ejecutarse en paralelo, en hilos distintos, sobre el mismo diccionario. Esto es justamente una carrera de datos. El FIFO de la cola solo garantiza el orden en que las tareas se entregan para ejecución, no que una tarea espere a que la anterior termine antes de arrancar, y mucho menos que se ejecuten en exclusión mutua entre sí. Proteger el acceso en este escenario requiere DispatchBarrier, cubierto en un artículo posterior.

Lo que viene

Falta ver el mismo tipo de cola concurrente, pero despachando con async en lugar de sync. Ese es el siguiente artículo.

Bibliografía

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

GoyesDev — Tue, 30 Jun 2026 23:08:55 +0000

Despachar un closure con async lo encola y retorna de inmediato. El hilo que hizo el llamado no espera a que el closure se ejecute. Sigue corriendo el código que viene después sin bloquearse.

Consideremos el siguiente fragmento de código, donde se despacha un bloque con async sobre una cola serial:

let serialQueue = DispatchQueue(label: "dev.goyes.gcd.serial")
var result: [Int] = []
let group = DispatchGroup()

result.append(1)

group.enter()
serialQueue.async {
  Thread.sleep(forTimeInterval: 1)
  result.append(2)
  group.leave()
}

result.append(3)

group.wait()

// result == [1, 3, 2]

DispatchGroup se cubre en detalle en un artículo posterior. Aquí solo hace falta saber que group.wait() bloquea hasta que todo lo que entró con group.enter() haya salido con group.leave(), y se usa únicamente para poder comprobar el resultado al final, no como parte de lo que se está demostrando.

Lo único garantizado en este código es que result.append(1) ocurre antes que cualquiera de los otros dos: es código síncrono, anterior al llamado a async. El orden entre result.append(3) y result.append(2) no está garantizado por la API: async retorna de inmediato, así que result.append(3) casi siempre se ejecuta primero, y por eso el resultado es [1, 3, 2] y no [1, 2, 3].

La cola sigue siendo serial: el orden entre tareas sí está garantizado

async cambia si el llamador espera, no cambia cómo procesa la cola las tareas. Una cola serial sigue ejecutando una tarea a la vez, en el orden en que se despacharon (FIFO), sin importar si se despacharon con sync o async.

Consideremos el siguiente fragmento de código, donde se despachan tres bloques con async sobre la misma cola serial:

let serialQueue = DispatchQueue(label: "dev.goyes.gcd.serial")
var result: [Int] = []
let group = DispatchGroup()

result.append(1)

for i in 2...4 {
  group.enter()
  serialQueue.async {
    Thread.sleep(forTimeInterval: 1)
    result.append(i)
    group.leave()
  }
}

result.append(5)

group.wait()

// result == [1, 5, 2, 3, 4]

result.append(5) se ejecuta de inmediato, antes de que cualquiera de las tres tareas asíncronas alcance a correr (cada una duerme un segundo completo antes de anotar su número). Pero el orden entre 2, 3 y 4 sí está garantizado por el FIFO de la cola serial: corren una a la vez, en el orden en que se despacharon, sin importar que ninguna haya bloqueado al llamador. Por eso no es necesario sincronizar la escritura sobre result entre las tres tareas: al ser una cola serial, nunca corren en paralelo entre sí, así que no se accede a result de forma concurrente en ningún momento.

`async` reentrante no produce deadlock

A diferencia de sync, llamar async sobre la misma cola serial en la que el código ya se está ejecutando es seguro. async nunca bloquea, así que solo agrega el closure al final de la cola y continúa.

Consideremos el siguiente fragmento de código, donde se llama async de forma anidada sobre la misma cola:

let serialQueue = DispatchQueue(label: "dev.goyes.serial")

serialQueue.async {
  print("Tarea A")
  serialQueue.async { // Seguro, no hay deadlock
    print("Tarea B")
  }
  print("A sigue ejecutando")
}

// Tarea A
// A sigue ejecutando
// Tarea B

La tarea A termina de ejecutarse por completo (incluyendo el print después del async anidado) antes de que la cola pase a la tarea B, porque B se encoló al final, detrás de lo que faltaba de A.

Por qué `Cache.write` usa `async`

En el artículo anterior, write(_:forKey:) despacha con async precisamente por esto: quien escribe en la caché no necesita esperar a que la escritura se aplique para seguir ejecutando. Lo único que importa es que, cuando se llegue a leer con sync, todas las escrituras encoladas antes ya se hayan procesado. Eso lo garantiza el FIFO de la cola serial, no el hecho de que el llamador haya esperado.

Lo que viene

Falta ver qué cambia cuando la cola, en lugar de serial, es concurrente: varias tareas pueden correr al mismo tiempo, y el FIFO deja de implicar "una a la vez". Eso es lo que cubren los siguientes dos artículos.

Bibliografía

[GCD] DQ Serial: ejecución síncrona y sincronización de hilos

GoyesDev — Tue, 30 Jun 2026 22:59:50 +0000

Despachar un closure con sync bloquea el hilo que hace el llamado hasta que ese closure termina de ejecutarse. El control no regresa al código que llamó a sync hasta que el trabajo encolado se completó.

Consideremos el siguiente fragmento de código, donde se despacha un bloque con sync sobre una cola serial:

let serialQueue = DispatchQueue(label: "dev.goyes.gcd.serial")
var result: [Int] = []

result.append(1)

serialQueue.sync {
  Thread.sleep(forTimeInterval: 1)
  result.append(2)
}

result.append(3)

// result == [1, 2, 3]

result.append(3) solo se ejecuta después de que el closure despachado con sync termina, incluyendo el segundo completo de Thread.sleep. Si sync no bloqueara, result sería [1, 3, 2] (el mismo resultado que se obtiene al despachar con async, cubierto en el artículo siguiente).

En una cola serial, sync se combina con dos propiedades ya cubiertas: el FIFO (las tareas empiezan en el orden en que se despachan) y la exclusión mutua de una cola serial (solo una tarea corre a la vez). El resultado es que sync no solo espera a que termine el closure despachado: espera a que termine después de que la cola haya procesado todo lo que estaba encolado antes.

Esto se sostiene incluso encadenando varias llamadas sync seguidas: cada una bloquea por completo antes de que el código que llama alcance la siguiente línea, así que se ejecutan una detrás de otra, en orden estricto.

Consideremos el siguiente fragmento de código, donde se encadenan tres llamadas sync seguidas sobre la misma cola serial:

let serialQueue = DispatchQueue(label: "dev.goyes.gcd.serial")
var result: [Int] = []

result.append(1)

serialQueue.sync {
  Thread.sleep(forTimeInterval: 1)
  result.append(2)
}

serialQueue.sync {
  Thread.sleep(forTimeInterval: 1)
  result.append(3)
}

serialQueue.sync {
  Thread.sleep(forTimeInterval: 1)
  result.append(4)
}

result.append(5)

// result == [1, 2, 3, 4, 5] (cada sync espera su segundo completo antes de que el código siga a la siguiente línea)

El error más común: deadlock por reentrada

Llamar sync sobre la misma cola serial en la que el código ya se está ejecutando produce un deadlock.

Consideremos el siguiente fragmento de código, donde se llama sync de forma anidada sobre la misma cola:

let serialQueue = DispatchQueue(label: "dev.goyes.serial")

serialQueue.sync {
  print("Tarea A")
  serialQueue.sync { // ⚠️ Deadlock
    print("Tarea B")
  }
}

La tarea A está corriendo dentro de la cola serial y bloquea ese hilo esperando a que la tarea B termine. Pero la tarea B no puede empezar: la cola es serial, solo procesa una tarea a la vez, y esa tarea (A) todavía no ha terminado: está esperando a B. Ninguna de las dos puede avanzar.

La versión real de este bug: `DispatchQueue.main.sync`

DispatchQueue.main es, para este propósito, una cola serial cuyo único hilo de ejecución es el hilo principal. Cualquier código que ya esté corriendo en el hilo principal (un método del ciclo de vida de UIKit como viewDidLoad(), una acción de botón, cualquier callback que llegue por el hilo principal) está, en términos de la cola, en la misma situación que la tarea A del ejemplo anterior.

Consideremos el siguiente fragmento de código, donde se llama DispatchQueue.main.sync desde viewDidLoad():

class SomeViewController: UIViewController {
  override func viewDidLoad() {
    super.viewDidLoad()
    DispatchQueue.main.sync { // ⚠️ Deadlock
      print("Esto nunca se imprime")
    }
  }
}

viewDidLoad() corre en el hilo principal. Al llamar DispatchQueue.main.sync, ese hilo se bloquea esperando a que el closure se ejecute, pero el único hilo donde la cola main puede ejecutar algo es justamente el que está bloqueado. El resultado es el mismo deadlock del ejemplo anterior, solo que disfrazado: no hace falta anidar sync explícitamente para reproducirlo, basta con llamar DispatchQueue.main.sync desde cualquier punto que ya esté corriendo en el hilo principal.

Usar `sync` como mecanismo de sincronización

La combinación de FIFO + exclusión mutua + bloqueo del llamador permite usar una cola serial para proteger el acceso a un recurso compartido, sin locks explícitos.

Consideremos el siguiente fragmento de código, donde una clase Cache usa una cola serial para sincronizar lecturas y escrituras:

final class Cache {
  private let queue = DispatchQueue(label: "dev.goyes.cache")
  private var storage: [String: Data] = [:]

  func write(_ value: Data, forKey key: String) {
    queue.async {
      self.storage[key] = value
    }
  }

  func read(forKey key: String) -> Data? {
    queue.sync {
      storage[key]
    }
  }
}

write despacha con async: no bloquea al llamador, solo encola la escritura. read despacha con sync: bloquea al llamador hasta que la lectura se ejecute, y por el FIFO de la cola, esa lectura solo corre después de que todas las escrituras encoladas antes ya se aplicaron. El resultado es lectura siempre consistente con el estado más reciente que se haya encolado, sin declarar ningún lock.

El costo de este enfoque es que las lecturas tampoco corren en paralelo entre sí: la cola es serial, así que dos llamados a read() desde hilos distintos también se serializan, aunque leer no modifique el estado y en principio no haya conflicto entre ellas. Ese costo es el que un DispatchQueue concurrente con DispatchBarrier evita, a cambio de más complejidad.

Lo que viene

Falta ver qué cambia cuando, sobre la misma cola serial, se despacha trabajo con async en lugar de sync. Eso es lo que cubre el siguiente artículo.

Bibliografía

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

GoyesDev — Tue, 30 Jun 2026 22:17:10 +0000

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 entrega, no necesariamente orden real de inicio

Una DispatchQueue es una cola FIFO (first in, first out): GCD entrega los closures para ejecución en el mismo orden en que se despacharon. En una cola serial esa garantía coincide con el orden real de inicio, porque solo hay un carril de ejecución: un closure no puede empezar hasta que el anterior termine.

En una cola concurrente esa coincidencia se rompe. GCD entrega los closures a hilos independientes en orden FIFO, pero una vez entregados, es el scheduler del sistema operativo (no GCD) quien decide cuándo cada hilo ejecuta su primera instrucción. Un closure despachado después puede imprimir su primera línea antes que uno despachado antes, sobre todo si requiere menos trabajo de arranque (por ejemplo, sync puede reutilizar el hilo que hace el llamado en lugar de pedir uno nuevo del pool, mientras que cada async sí necesita adquirirlo). El artículo de DQ Concurrente: ejecución síncrona muestra un caso real de esto.

El orden de finalización tampoco está garantizado en una cola concurrente. Eso depende de si la cola es serial o concurrente, lo cual se cubre en los próximos dos artículos. Lo único que GCD garantiza siempre, en cualquier tipo de cola, es el orden de entrega FIFO descrito arriba.

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: "dev.goyes.tareas")

// 3b. Cola propia, hecha concurrente explícitamente
let customConcurrent = DispatchQueue(label: "dev.goyes.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

[GCD] Gestionando hilos de forma segura y optimizada

GoyesDev — Tue, 30 Jun 2026 22:04:40 +0000

Antes de Grand Central Dispatch (GCD), escribir código concurrente en Cocoa significaba administrar hilos a mano: crear un NSThread o un pthread, decidir cuántos crear, sincronizar el acceso a los datos compartidos con locks, y destruirlos cuando ya no se necesitaban. Cada una de esas decisiones era responsabilidad del desarrollador, y cada una era una oportunidad para introducir un bug: crear demasiados hilos, olvidar un lock, o dejar un hilo vivo más tiempo del necesario.

Apple presentó GCD en el WWDC de 2009, junto con Mac OS X Snow Leopard. Su implementación, libdispatch, se liberó como código abierto ese mismo año. La idea central fue cambiar la pregunta que se hace el desarrollador: en lugar de pensar "¿en qué hilo va a correr esto?", GCD propone pensar "¿en qué cola va a correr esto?".

El cambio de modelo: de hilos a colas

En GCD no se crean hilos directamente. Se envía un bloque de trabajo (un closure) a una DispatchQueue, y es el sistema operativo quien decide en qué hilo se ejecuta, cuándo, y cuántos hilos mantener vivos. El desarrollador delega esa responsabilidad.

Consideremos el siguiente fragmento de código, donde se despacha trabajo tanto a la cola global concurrente como a la cola principal, y se comprueba en qué hilo corre cada una:

DispatchQueue.global(qos: .default).async {
  print(Thread.current != Thread.main) // true, corrió en un hilo de segundo plano
}

DispatchQueue.main.async {
  print(Thread.current == Thread.main) // true, corrió en el hilo principal
}

No hay creación explícita de hilos en ninguno de los dos casos. Solo se describe el trabajo y se envía a una cola. Es la cola la que decide en qué hilo corre: una cola global concurrente usa un hilo de segundo plano; la cola principal siempre usa el hilo principal.

¿Por qué es "seguro y optimizado"?

Seguro, porque la cola es la responsable de administrar el ciclo de vida de los hilos. Ya no se gestiona manualmente la creación ni la destrucción, lo que elimina una categoría entera de errores propios de la administración manual de hilos.

Optimizado, porque GCD ajusta el tamaño del pool de hilos según la cantidad de núcleos disponibles y la carga del sistema en tiempo de ejecución, en lugar de usar un número fijo de hilos decidido a priori por el desarrollador. Esto evita tanto la sub-utilización del CPU (pocos hilos, núcleos desaprovechados) como la sobre-asignación (más hilos que núcleos, con el costo de cambio de contexto que eso implica).

Lo que viene

GCD organiza el trabajo en DispatchQueue, que es el concepto central de todo lo demás en este módulo: tipos de cola, prioridad, y las distintas formas de despachar tareas (síncrona vs. asíncrona, serial vs. concurrente). Eso es lo que cubre el siguiente artículo.

DEV Community: GoyesDev

[GCD] Problemas de GCD

Complejidad conceptual: hilo y cola son dos cosas distintas

Completion handlers anidados

Manejo de errores doloroso

Propenso a olvidar llamar el closure de callback

Carrera de datos sin protección del compilador

Explosión de threads

Inversión de prioridad

Lo que viene

Bibliografía

[GCD] Sincronización de hilos con DispatchSemaphore

Qué es un semáforo: wait() y signal()

Limitar cuántas tareas acceden a un recurso al mismo tiempo

Semáforo con contador 1: el mismo efecto que una barrera, sin cola dedicada

Convertir una API con callback en código que bloquea

wait() en el hilo principal bloquea la interfaz

Diferencia con DispatchGroup: signal() de más no falla de inmediato

Lo que viene

Bibliografía

[GCD] Sincronización de hilos con DispatchBarrier

Qué hace una barrera

Cómo despachar una tarea con .barrier

Orden garantizado alrededor de la barrera

Usar una barrera para proteger lecturas y escrituras

Cuándo no usar una barrera

Lo que viene

Bibliografía

[GCD] Sincronización implícita y explícita con DispatchGroup

Marcar entrada y salida de forma explícita: enter(), leave() y notify(queue:execute:)

Error común: llamar enter() dentro del bloque async

Forma implícita: async(group:execute:)

El riesgo de async(group:execute:): callbacks anidados

Sincronización bloqueante con wait()

Balance estricto entre enter() y leave()

Más leave() que enter()

Más enter() que leave(): el grupo nunca se vacía

Lo que viene

Bibliografía

[GCD] Cancelando un DispatchWorkItem

Cancelar antes de que empiece a correr

Cancelar mientras ya está corriendo: cancelación cooperativa

wait() sigue funcionando igual con un DispatchWorkItem cancelado

Lo que viene

Bibliografía

[GCD] Trabajando con DispatchWorkItem

Creando y despachando un DispatchWorkItem

Ejecutarlo directamente con perform()

Esperar su finalización con wait()

Recibir una notificación al terminar con notify(queue:execute:)

Lo que viene

Bibliografía

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

Reentrada: sigue siendo segura

El riesgo: nada serializa el acceso a estado compartido

Lo que viene

Bibliografía

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

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

sync bloquea por esa tarea, no por la cola

El orden de entrega FIFO no garantiza el orden real de inicio

Esa ventaja no garantiza que sync siempre termine primero

Encadenar varios sync sí produce orden determinista

El riesgo: sync no implica exclusión mutua

Lo que viene

Bibliografía

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

La cola sigue siendo serial: el orden entre tareas sí está garantizado

async reentrante no produce deadlock

Por qué Cache.write usa async

Lo que viene

Bibliografía

[GCD] DQ Serial: ejecución síncrona y sincronización de hilos

El error más común: deadlock por reentrada

La versión real de este bug: DispatchQueue.main.sync

Usar sync como mecanismo de sincronización

Lo que viene

Bibliografía

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

FIFO: orden de entrega, no necesariamente orden real de inicio

`sync` bloquea por esa tarea, no por la cola

Esa ventaja no garantiza que `sync` siempre termine primero

Encadenar varios `sync` sí produce orden determinista

El riesgo: `sync` no implica exclusión mutua

`async` reentrante no produce deadlock

Por qué `Cache.write` usa `async`

La versión real de este bug: `DispatchQueue.main.sync`

Usar `sync` como mecanismo de sincronización