DEV Community: GoyesDev

[SC] Actores globales

GoyesDev — Mon, 13 Apr 2026 23:05:25 +0000

Preguntas

¿En qué se diferencia un actor global de un actor regular?

Un actor regular serializa el acceso a los datos que tiene encapsulados. Un actor global, permite definir valores, tipos de datos o métodos, fuera del scope del actor para que sea ejecutados con su executor.

¿A qué se parece un actor global conceptualmente, y en qué se diferencia de ese concepto?

Un actor global se parece a un singleton. Sin embargo, la diferencia radica en el uso: realmente no se "usa" el actor, sino que se "anotan" propiedades, funciones y tipos de datos para que se ejecuten dentro del executor del actor.

¿A qué elementos del código se puede aplicar un actor global?

Valores, tipos de datos (e.g. clase), funciones.

¿Por qué el estado global es peligroso en programas concurrentes y cómo lo resuelven los actores globales?

Una tarea puede estar escribiendo en el estado global, mientras que otra puede estar leyendo. Esto provoca una carrera de datos.
Un actor global sería como marcar esa información (valor, tipo de dato, función) con un cartel que dice "acceso solo serializado".

¿Qué atributo se usa para definir un actor global personalizado y qué protocolo debe conformar?

Un actor global personalizado se define con @globalActor, debe conformar el protocolo GlobalActor y esto se logra definiendo la propiedad shared.

¿Qué propiedad es obligatoria para conformar al protocolo `GlobalActor`?

Se debe definir shared.

¿Qué problema introduce no tener un inicializador privado en un actor global?

Podría existir otro actor con un executor diferente, cuando el objetivo del actor global es poder tener un solo executor.

¿Por qué se recomienda usar `private init()` en un actor global y qué previene?

El objetivo es impedir que se cree otra instancia del actor global.

¿Cómo se usa un actor global personalizado una vez definido?

Supongamos que se marca con @globalActor al actor llamado ActorType. Luego, se puede marcar con @ActorType una variable global, un método o un tipo de dato.

¿En qué se parece al uso de `@MainActor`?

@MainActor es un actor global que serializa el acceso al executor de la interfaz gráfica.

¿Qué ventaja tiene aislar todo el procesamiento de imágenes bajo un mismo actor global?

Quiero que todo lo relacionado con el procesamiento de imágenes pase de forma serial: solo quiero procesar una imagen a la vez.

Recitar

Sin mirar el texto, responde:

¿Qué tres tipos de elementos del código puede anotar un actor global?

¿Qué pasa si alguien llama `ImageProcessing()` directamente sin el inicializador privado?

¿Por qué `@MainActor` es considerado un actor global?

Revisión

¿Cuál es la diferencia entre un actor regular y uno global en cuanto a su alcance?

¿Qué garantía en tiempo de compilación ofrece un actor global?

¿Qué requisito mínimo debe cumplir un tipo para conformar a `GlobalActor`?

¿Qué consecuencia tendría tener dos instancias del actor `ImageProcessing` en ejecución?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Actores en Swift

GoyesDev — Mon, 13 Apr 2026 22:20:27 +0000

Preguntas

¿Qué es un `actor` en Swift Concurrency y en qué se diferencia de una clase?

Un actor es un tipo de dato por referencia, parecido a un class.
actor no puede heredar de otros tipos de datos, a excepción de NSObject.
actor garantiza acceso serializado a los datos que encapsula.
No se puede modificar directamente los datos de actor, sino que se debe hacer a través de métodos, que deben ser invocados con await.
Se puede leer los datos del actor de forma asíncrona, con await.

¿Qué garantía fundamental ofrece el aislamiento de actores (actor isolation)?

Solo una tarea puede acceder a los datos de forma simultánea.

¿Por qué no puedes mutar directamente una propiedad de un actor desde fuera de él, aunque no sea private?

La mutación debe pasar por el executor del actor para que este la serialice.

¿Qué es un executor y cuál es su función dentro de un actor?

Un executor es una especie de cola serial que gestiona el acceso al dominio de aislamiento del actor.

¿En qué se diferencia el executor de un actor de una `DispatchQueue` serial?

DispatchQueue serial bloquea el hilo, mientras que el actor es reentrante, dado que su executor puede ejecutar otras tareas cuando se encuentra con await.

¿Por qué siempre debes usar `await` para acceder a propiedades o métodos de un actor?

Puede ser que otra tarea esté modificando o leyendo una propiedad del actor, así que hay que esperar hasta poder acceder a ella.

¿Cuál es la diferencia entre leer y mutar una propiedad de un actor desde fuera?

Se puede leer con await pero no se puede mutar desde fuera.

¿Por qué los actores no soportan herencia y qué implica eso en la práctica?

La responsabilidad del actor es aislar el acceso a los datos, así que no hay que usar open, final u override.
En la práctica implica que hay que usar composición sobre herencia.

¿Cuál es la única excepción a la regla de no herencia en actores, y para qué sirve?

Un actor puede heredar de NSObject y sirve para interoperabilidad con ObjC.

¿Qué analogía usa el artículo para describir el acceso a un actor y por qué es adecuada?

Un actor es como un semáforo: Si de entrada está en verde, puedo pasar. Si está en rojo, debo esperar. - Esto es esencialmente lo que pasa con await.

Recitar

Sin mirar el artículo, responde con tus propias palabras:

¿Cómo serializa el acceso un actor internamente?

¿Qué error produce el compilador si intentas mutar balance directamente?

¿Qué hace un actor cuando uno de sus métodos llega a un `await`?

Revisión

¿En qué se parece y en qué se diferencia un actor de una clase?

¿Qué problema resuelve el actor que no resolvía NSLock automáticamente?

¿Por qué el executor de un actor sí puede ser reentrante y una `DispatchQueue` serial no?

Si un `actor` es un tipo referencia, ¿cómo garantiza igualmente la seguridad de datos?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Combinando Sendable con Locks personalizados

GoyesDev — Mon, 13 Apr 2026 15:22:47 +0000

Q — Questions (Preguntas)

Convierte los encabezados en preguntas de estudio:

¿Qué es un mecanismo de bloqueo (`lock`) y para qué se usa en concurrencia?

Un "lock" es un mecanismo de sincronización de hilos que sirve para proteger el acceso y modificación de un dato. Se usa en concurrencia para que no haya carreras de datos.

¿Cómo protege `NSLock` el acceso a datos mutables compartidos en la clase `BankAccount`?

En BankAccount hay una propiedad, balance que se debe proteger con un NSLock: Cada vez que se accede al método se bloquea (.lock()) y justo antes de salir de cada método se libera (.unlock()).

¿Por qué el ejemplo de `BankAccount` es útil para entender los actores más adelante?

En el contexto de concurrencia de Swift, el actor permite invocar sus métodos con await con lo que consigue serializar los accesos a los datos. Si se va a escribir código nuevo, lo ideal es usar un actor. Sin embargo, en código pre-existente hay que evaluar si basta con usar @unchecked Sendable.

El ejemplo inicial de BankAccount ilustra el acceso a balance de forma serializada con ayuda del NSLock. Usar el lock es una convención. Por otro lado, la implementación con actor también serializa el acceso a los datos (en este caso, balance) con la diferencia de que aquí no hay ninguna convención sino que el lenguaje garantiza este comportamiento.

¿En qué situaciones conviene usar `@unchecked Sendable` en lugar de refactorizar a un actor?

Si el código es bastante estable, la sincronización del acceso a datos es segura, y si la clase en cuestión tiene muchos clientes y su refactorización puede ser compleja, se puede usar @unchecked Sendable.

¿Qué implica técnicamente migrar una clase con locks a un actor en Swift?

Acceder a todos los métodos requiere usar await, lo que implica que el consumo es asíncrono.

¿Cuáles son las desventajas de migrar de inmediato a un actor en una base de código existente?

Se tendría que modificar a todos los clientes para invocar los métodos del actor con await.

¿Cuándo se recomienda usar `Mutex` en lugar de `NSLock` o actores?

Si se quiere sincronizar los hilos y también tener acceso a la clase en cuestión de forma síncrona, entonces se usa Mutex.

R — Recite (Recitar)

Sin mirar el texto, responde con tus propias palabras:

¿Cómo funciona el flujo de bloqueo/desbloqueo en `BankAccount`?

final class BankAccount: @unchecked Sendable {
  private var balance: Int = 0
  private let lock = NSLock()

  func deposit(amount: Int) {
    lock.lock()
    balance += amount
    lock.unlock()
  }

  func withdraw(amount: Int) {
    lock.lock()
    if balance >= amount {
      balance -= amount
    }
    lock.unlock()
  }

  func getBalance() -> Int {
    lock.lock()
    let currentBalance = balance
    lock.unlock()
    return currentBalance
  }
}

actor BankAccount {
  private var balance: Int = 0

  func deposit(amount: Int) {
    balance += amount
  }

  func withdraw(amount: Int) {
    if balance >= amount {
      balance -= amount
    }
  }

  func getBalance() -> Int {
    return balance
  }
}

¿Qué garantiza `@unchecked Sendable` y qué responsabilidad transfiere al desarrollador?

¿Qué cambia en el código que consume `BankAccount` cuando se migra a actor?

R — Review (Revisión)

Preguntas de repaso para consolidar:

¿Cuál es la diferencia entre una clase con `NSLock` y un actor en términos de acceso concurrente?

¿Por qué `@unchecked Sendable` es una solución temporal y no definitiva?

¿Qué acción concreta recomienda el autor para no olvidar la deuda técnica al usar `@unchecked Sendable`?

¿Qué factores debes considerar antes de decidir si migrar a un actor de inmediato?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Valores globales seguros para concurrencia

GoyesDev — Sat, 11 Apr 2026 17:16:39 +0000

Preguntas

¿Qué es una variable global y por qué su uso implica riesgos en contextos de concurrencia?

Una variable global es un valor que puede ser accedido y modificado desde cualquier parte del sistema, esto incluye cualquier contexto asíncrono.

¿Qué error genera el compilador de Swift 6 cuando una variable global es mutable y no está aislada?

Tomemos como ejemplo la clase no aislada ImageCache, que tiene una variable global mutable no aislada llamada shared. En este caso, el compilador saca un error indicando que no es seguro acceder a un estado global mutable desde un entorno concurrente.

nonisolated class ImageCache {
  static var shared = ImageCache()
  // ❌ Static property 'shared' is not concurrency-safe because it is nonisolated global shared mutable state
}

¿Cuáles son las tres estrategias principales para hacer una variable global segura para la concurrencia?

1. Aislar el acceso a la clase con un actor global como `@MainActor`.

Ventaja: @MainActor garantiza que el acceso a ImageCache es serializado.
Desventaja: Complica el acceso desde otros dominios de aislamiento o contextos no-concurrentes

Por ejemplo:

@MainActor
class ImageCache {
  static var shared = ImageCache()
  // ✅ No hay error
}

nonisolated class NonConcurrentContext {
  func execute() {
    let sut = ImageCache.shared
    // ❌ Main actor-isolated static property 'shared' can not be referenced from a nonisolated context
  }
}

fileprivate actor ActorContext {
  func execute() {
    let sut = ImageCache.shared
    // ❌ Main actor-isolated static property 'shared' can not be referenced on a nonisolated actor instance
  }
}

2. Conformar `Sendable`

Esto es:

Hacer que la clase sea inmutable.
Marcar con final
Mutar las variables por medio de locks.

Recordar que el protocolo Sendable indica que el API del tipo en cuestión es thread-safe y se puede usar sin problema entre dominios de aislamiento.

// ✅ final
nonisolated final class ImageCache: Sendable {

  static let shared = ImageCache()
  // ✅ let, no var

  func clearCache() {
    // ...
  }
}

fileprivate actor ActorContext {
  func execute() {
    let sut = ImageCache.shared
    // ✅ No hay error
  }
}

fileprivate nonisolated class NonConcurrentContext {
  func execute() {
    let sut = ImageCache.shared
    // ✅ No hay error
  }
}

3. Marcar el tipo como `Sendable` y la propiedad mutable como nonisolated(unsafe)

Si el API no se puede modificar con facilidad (para conformar Sendable) y tiene partes mutables, se puede marcar a estas últimas como nonisolated(unsafe), que es el equivalente a usar @unchecked Sendable. Básicamente se le está diciendo al compilador que el desarrollador se hace responsable de sincronizar el acceso a ese valor global, sin introducir data-races.

Lo ideal es solo modificar el valor global en el arranque de la aplicación y luego leerlo desde otros contextos de concurrencia, para lo cual se puede usar el modificador private(set).

¿Cuándo y por qué se usaría `nonisolated(unsafe)` en lugar de las otras soluciones?

Cuando el código tiene un patrón de inicialización tardía que no puedo reescribir fácilmente.

¿Qué condiciones debe cumplir una clase para conformar al protocolo `Sendable`?

marcada como final.
miembros inmutables.
acceso a miembros mutables por medio de locks.

Lectura

¿Por qué aislar una clase con `@MainActor` puede ser problemático en algunos casos?

El acceso desde otros dominios de aislamiento o nonisolated tendrá que ser usando await.

¿Qué papel juega `private(set)` cuando se usa junto con `nonisolated(unsafe)`?

El objetivo es que solo la clase que define el singleton pueda modificar la variable estática y que ningún cliente lo haga.

¿En qué se parece `nonisolated(unsafe)` al uso de `@unchecked Sendable`?

Se le dice al compilador que el desarrollador se compromete a garantizar que no hay carreras de datos.

Revisión

Sin volver atrás ¿puedes explicar con tus propias palabras qué hace que una variable global sea peligrosa en Swift 6?

¿Puedes describir de memoria los pasos para convertir `ImageCache` en una clase segura para la concurrencia?

¿Cuál de las tres soluciones presentadas consideras más adecuada para un proyecto en producción y por qué?

¿Qué riesgos asumes al marcar una variable como `nonisolated(unsafe)`, y cómo podrías mitigarlos?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Aislamiento basado en regiones y la palabra clave "sending"

GoyesDev — Sat, 11 Apr 2026 00:34:13 +0000

Preguntas

¿Qué es el aislamiento basado en regiones (region-based isolation) y por qué existe?

El sistema original de Sendable era demasiado estricto y bloqueaba patrones de código seguros que usaban código no-Sendable. Por esto se creó el "aislamiento basado en regiones", el cual es un mecanismo del compilador que verifica si un tipo no-Sendable se usa únicamente dentro de un scope.

¿En qué situaciones el compilador ignora errores de tipos no-`Sendable`?

Si se crea un valor localmente dentro de una función, no se muta y no se accede a él después de transferirlo a otro dominio de aislamiento, entonces el compilador puede garantizar que no hay acceso simultáneo.

¿Qué son los diagnósticos sensibles al flujo de control (control flow-sensitive diagnostics)?

El "diagnóstico sensible al flujo de control" es un análisis de código estático que hace el compilador para determinar que un tipo no-Sendable puede transferirse de forma segura a otro dominio de aislamiento.

El compilador revisa si el valor se usa o no después del punto de transferencia.

¿Cuándo deja de compilar el código aunque se use aislamiento basado en regiones?

Cuando se usa el valor después de haberlo transferido a otro dominio de aislamiento.

¿Qué problema resuelve la palabra clave `sending`?

sending declara explícitamente una transferencia de propiedad, por lo que compilador mueve las verificaciones hacia el interior del método receptor.

De esta forma se puede silenciar un posible error cuando el desarrollador sabe que no hay riesgo de data-race.

¿Cuál es la diferencia entre usar `sending` en parámetros y en valores de retorno?

sending como parámetro garantiza que el invocador del método no puede volver a utilizar la propiedad. Además, solo se puede transferir a un solo dominio de aislamiento.
sending como retorno indica que la función no conserva referencia al valor y lo transfiere hacia fuera.

¿Por qué un tipo no-`Sendable` dentro de un método local no genera error al pasarse a una `Task`?

El compilador es capaz de identificar que el valor nació en esa función, nadie más tiene referencia a él y, si no se accede después del Task, no puede haber un acceso simultáneo.

¿Qué ocurre si accedes a un valor después de haberlo transferido con `sending`?

El compilador indica que se está usando el valor transferido y los accesos posteriores podrían generar una condición de carrera.

Ejemplos con código

Article es una clase no-Sendable.

nonisolated class Article {
  var title: "String"

  init(title: "String) {"
    self.title = title
  }
}

Puedo recibir un Article y pasárselo de forma segura UN SOLO dominio de aislamiento. Para ello, puedo modificar un parámetro con sending:

nonisolated final class ArticleConsumer {
  func execute(article: sending Article) {
    Task {
    // ❌ Sending value of non-Sendable type '@concurrent () async -> ()' risks causing data races
      print(article.title)
    }
    print(article.title)
  }
}

En este caso, la clase ArticleConsumer vive en el dominio nonisolated. En el método execute(article:), se transfiere article desde nonisolated hasta la región sin estructura del Task. En este punto, el método que transfiere (i.e. execute(article:) ya no puede volver a usarlo (i.e. llamar print(article.title).

Con lo anterior quiero decir que al usar sending solo se puede transferir el dato a través de UN SOLO dominio de aislamiento.

Sucede lo mismo en el siguiente escenario, donde el dominio de aislamiento al que se transfiere article es un actor en lugar de un Task:

actor ArticleStore {
  func save(_ article: Article) {
    print(article.title)
  }
}

nonisolated final class ArticleConsumerWithActor {
  func execute(article: sending Article) async {
    let store = ArticleStore()
    await store.save(article)
    // ❌ Sending 'article' risks causing data races
    print(article.title)
  }
}

No obstante, todo este análisis funciona porque tanto ArticleConsumerWithActor como ArticleConsumer están marcados con nonisolated. Si no tuvieran ese modificador y tuviéramos las propiedades de configuración del proyecto SWIFT_DEFAULT_ACTOR_ISOLATION = MainActor y SWIFT_VERSION = 6.0, entonces tanto ArticleConsumerWithActor como ArticleConsumer vivirían en @MainActor implícitamente.

Luego, cuando se crea un Task dentro del contexto aislado MainActor, la Task hereda el mismo aislamiento MainActor. De esta forma, tanto la Task como el cuerpo del método ArticleConsumer.execute(article:) vivirán en @MainActor. Más tarde, cuando el compilador hace el análisis de código estático para el dianóstico de regiones encontrará que no se está cruzando ninguna región y usar article después del Task es legal.

// ⚠️ hereda @MainActor implícitamente
final class ArticleConsumer {
  func execute(article: sending Article) {
    Task {
      // ✅ No saca ningún error
      print(article.title)
    }
    print(article.title)
  }
}

Recitación

Explica con tus propias palabras cómo el compilador determina si hay riesgo de data race.

El compilador sigue el código y marca el punto donde un valor se transfiere de un dominio a otro. Si no se vuelve a transferir, no hay problema. Si, en cambio, se transfiere, entonces hay dos zonas con acceso potencial simultáneo y saca un error.

¿Por qué agregar un `print` después de la transferencia rompe la compilación?

La Task podría estar ejecutándose en paralelo al tiempo que el print. Esas dos zonas pueden acceder simultáneamente al mismo valor, y esto es lo que quiere prevenir Swift.

Revisión

¿En qué casos concretos usarías `sending` en lugar de conformar un tipo a `Sendable`?

La clase en cuestión no puede ser Sendable. Pueden tener estado mutable pero en cierto contexto pasa de forma controlada y sin acceso concurrente.

¿Cómo reduce el aislamiento basado en regiones la necesidad de usar `Sendable`?

El compilador analiza cada caso específicamente. Si en un scope es seguro usar un valor, no es necesario que conforme Sendable.

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] @unchecked Sendable

GoyesDev — Fri, 10 Apr 2026 16:52:05 +0000

Preguntas

¿Qué significa exactamente `@unchecked Sendable` y en qué se diferencia de `Sendable` normal?

@unchecked Sendable significa que un tipo de dato específico conforma el contrato Sendable pero, a pesar de que el compilador podría no ser capaz de garantizar las condiciones del contrato, el desarrollador remueve esa validación y él se compromete a sincronizar el acceso a datos.

¿En qué situaciones es apropiado usar `@unchecked Sendable`?

Se puede usar @unchecked Sendable si el código ha demostrado ser seguro en un ambiente concurrente y se usa como solución temporal/intermedia hasta que se migre a un actor.

El acceso a datos debe controlarse internamente con un lock.

¿Qué riesgos concretos introduce el uso de `@unchecked Sendable`?

Puede ser que el día que se agregue @unchecked Sendable a una clase esta en realidad sea segura para usar en un ambiente concurrente. Sin embargo, no hay certeza de que el día de mañana alguien agregue una funcionalidad a la clase y haya pasado por alto la sincronización de los hilos para acceder a los datos.

Por ejemplo, considerar la clase:

nonisolated final class ArticleTitlesCache: @unchecked Sendable {
  private let cacheMutatingLock = DispatchQueue(label: "cache.lock.queue")

  private var articleTitles: Set<String> = []

  func addArticleTitle(_ title: String) {
    cacheMutatingLock.sync {
      _ = articleTitles.insert(title)
    }
  }

  func cachedArticleTitles() -> Set<String> {
    return cacheMutatingLock.sync {
      return articleTitles
    }
  }
}

El día de mañana, se quiere agregar una funcionalidad para contar el número de artículos almacenados que, idealmente, se construiría así:

Alguien el día de mañana podría olvidar envolver con cacheMutatingLock la nueva funcionalidad:

var count: Int {
  cacheMutatingLock.sync {
    articleTitles.count
  }
}

Sin embargo, se pasó por alto la sincronización de los hilos y se escribió así:

var count: Int {
  articleTitles.count
}

¿Por qué el compilador no puede verificar la seguridad de hilos cuando se usa un `DispatchQueue` como `lock`?

El compilador verifica que una implementación sea segura en términos de concurrencia de forma estructural y estática que implica el uso de valores inmutables, tipos de datos Sendable, y sincronización de hilos por medio de dominios de aislamiento y async/await.

Usar DispatchQueue correctamente para sincronizar hilos requiere una convención de comportamiento en tiempo de ejecución - El día de mañana un desarrollador puede olvidar sincronizar los hilos con DispatchQueue y el comportamiento se daña.

¿Cuál es la alternativa recomendada a `@unchecked Sendable` y por qué es superior?

Se recomienda usar Sendable (sin @unchecked).

Recitación

¿Puedes explicar con tus propias palabras qué ocurre si se accede a `articleTitles` sin pasar por `cacheMutatingLock`?

Puede ocurrir una carrera de datos.

¿Qué ventaja ofrece usar un `actor` frente a un `lock` manual?

El actor le da al compilador una garantía estructural: sabe por diseño que todo acceso a su estado está serializado.

Repaso

¿En qué escenario específico el artículo acepta `@unchecked Sendable` como solución válida, y qué condición impone para usarlo?

Es válido poner @unchecked Sendable es una clase que se sabe que es segura para usar en ambientes concurrentes (lo ha sido por mucho tiempo) y se programa una migración para convertirla en actor (con un ticket, por ejemplo).

Si tuvieras que migrar `ArticleTitlesCache` a un `actor`, ¿qué cambios estructurales serían necesarios?

Se elimina la sincronización con DispatchQueue y todos los llamados de los clientes tendrían que cambiar para usar await.

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Closures con @Sendable

GoyesDev — Thu, 09 Apr 2026 22:06:53 +0000

Preguntas

¿Por qué no basta con el protocolo `Sendable` para funciones y closures?

Los closures y funciones pueden capturar valores. A la hora de usar un closure o una función en un entorno concurrente, es posible que sea necesario pasarlo a través de varios dominios de aislamiento y, por tanto, también se debe garantizar que los valores capturados sean seguros.

Actualmente los closures y funciones no pueden conformar el protocolo Sendable, sin embargo, la etiqueta @Sendable le permite al compilador validar que el closure o función sea seguro para pasar entre dominios de aislamiento.

¿Qué garantía ofrece `@Sendable` al compilador sobre los valores capturados?

@Sendable garantiza que los valores capturados deben ser Sendable y también deben ser capturados por valor. Esto último puede ser algo confuso inicialmente, sin embargo, espero poder aclararlo con los siguiente ejemplos:

El siguiente closure captura un Int escalar, así que tiene una referencia directa a su valor.

func execute() -> () -> Int {
  return {
    return 1 + 1
  }
}

Puedo extraer el Int escalar y moverlo a una constante por fuera. En este caso, el closure va a tener una copia del valor de esa constante. Una vez que termina el scope de execute() la variable x se libera del stack, mientras que el closure retornado va a conservar una copia del valor que tenía.

func execute() -> () -> Int {
  let x = 1
  return {
    return x + 1
  }
}

Si x es una variable, Swift internamente genera una caja para almacenar el valor y poder referenciarla desde el closure después. En efectos prácticos, estaría moviendo un valor del stack al heap.

Consideremos el siguiente código:

func execute() -> () -> Int {
  var x = 1
  return {
    return x + 1
  }
}

Swift internamente haría lo siguiente:

// Swift crea un "box" en el heap para almacenar x
class Box<T> {
    var value: T
    init(_ value: T) { self.value = value }
}

func execute() -> () -> Int {
  let x = Box(1)
  return {
    return x + 1
  }
}

En código de un solo hilo no habría ningún problema, sin embargo, si se marca execute() con @Sendable, entonces aparecería un error como el siguiente:

// Reference to captured var ‘x’ in concurrently-executing code

Por esta razón, hay que usar un capture list, para guardar una copia de la variable en la definición del closure. Esto sería un "snapshot".

func execute() -> () -> Int {
  var x = 1
  return { [x] in
    return x + 1
  }
}

¿Cuándo es necesario cruzar dominios de aislamiento (isolation domains) con una función?

Como regla general, se dice que una función necesita cruzar un dominio de aislamiento cuando se crea en un dominio, pero se ejecuta en otro. Esta situación puede presentarse en los siguientes escenarios:

1. Pasar callbacks o predicados a un actor

actor OrdersStore {
  private(set) var orders: [Order] = []
  func filter(_ isIncluded: @Sendable (Order) -> Bool) -> [Order] {
    orders.filter(isIncluded)
  }
}

let store = OrdersStore()
let expensiveOrders = await store.filter {
  order in order.total > 1000
}

En el caso anterior, se define el predicado en el contexto del invocador y se pasa al actor OrdersStore cuando se invoca await store.filter.

2. Tareas en segundo plano

actor ImageProcessor {
    func process(_ image: UIImage) -> UIImage {
        // procesamiento pesado...
        return image
    }
}

let processor = ImageProcessor()

func processInBackground(
  image: UIImage, 
  transform: @escaping @Sendable (UIImage) -> UIImage) {
    Task(priority: .background) {
      let result = transform(image)         // dominio de la Task
      await processor.process(result)       // dominio del actor
    }
}

En el ejemplo anterior, el closure recibido por parámetro transform se originó en el dominio del invocador y luego se pasó al dominio del Task.

3. Programación funcional con actores

actor ProductCatalog {
  private(set) var products: [Product] = []

  func apply(
    filter: @Sendable (Product) -> Bool,
    transform: @Sendable (Product) -> Product
  ) -> [Product] {
    products
      .filter(filter)
      .map(transform)
  }
}

let catalog = ProductCatalog()
let discounted = await catalog.apply(
  filter: { $0.stock > 0 },
  transform: { product in
    var p = product
    p.price *= 0.9  // 10% de descuento
    return p
  }
)

En este ejemplo, dos funciones de orden superior se crearon en el contexto invocador y luego se pasan al actor.

4. Código `nonisolated` que delega trabajo a un actor

actor NotificationsStore {
    private(set) var notifications: [Notification] = []

    func removeAll(where condition: @Sendable (Notification) -> Bool) {
        notifications.removeAll(where: condition)
    }
}

extension NotificationsStore {
    nonisolated func cleanUpInBackground(
        _ shouldRemove: @escaping @Sendable (Notification) -> Bool
    ) {
        Task(priority: .background) {
            await removeAll(where: shouldRemove)
        }
    }
}

// Uso:
let notificationsStore = NotificationsStore()
notificationsStore.cleanUpInBackground { notification in
    notification.isRead && notification.age > 30
}

A pesar de que Swift Concurrency define nonisolated como un dominio de aislamiento, en principio no es un dominio propio porque no protege datos ni sincroniza acceso. Por eso, en principio, cleanUpInBackground es código que vive fuera de cualquier actor. Luego, shouldRemove viaja así:

Invocador a nonisolated: el closure entra como parámetro a cleanUpInBackground.
nonisolated a Task: el closure es capturado por el bloque Task(priority: .background), cruzando hacia el dominio de la tarea. Aquí es donde @escaping y @Sendable son necesarios.
Task a actor: el closure se pasa a removeAll(where:) con await, cruzando hacia el dominio del actor.

¿Qué diferencia hay entre capturar una variable `let` y una `var` dentro de un closure `@Sendable`?

Cuando se captura un var dentro de un closure, en realidad se envuelve el valor en una especie de caja que, en sentido práctico, mueve el valor del stack al heap. Como pasar esta referencia entre dominios de aislamiento es inseguro, al usar @Sendable aparece el error de compilación:

// Reference to captured var ‘x’ in concurrently-executing code

¿Para qué sirve una capture list y cuándo es obligatorio usarla?

Una capture list sirve para tomar una fotografía inmutable del valor de una variable en el momento en que se crea el closure, en lugar de capturar una referencia a esa variable, lo que satisface el requisito de inmutabilidad de @Sendable.

¿Qué errores de compilación aparecen si se pasa un closure entre dominios de aislamiento sin marcarlo como `@Sendable`?

// Passing closure as a sending parameter risks causing data races between code in the current Task and the concurrent execution of the closure.

// Sending task-isolated value of type ‘(X) -> Y’ with later accesses to actor-isolated context risks causing data races

¿Cómo cambia el comportamiento del compilador al agregar `@Sendable` al parámetro `shouldBeRemoved`?

El compilador puede verificar que los valores capturados por el closure sean Sendable.

¿Por qué el compilador rechaza capturar una var de tipo String aunque String sea un value type?

Porque cuando un closure captura una variable, se crea una caja que la mueve del stack al heap. Por esta razón, se tiene que trabajar con valores inmutables.

¿Qué significa "capturar por valor" (capture by-value) y qué problema evita?

Capturar por valor significa que el closure se queda con una copia independiente del valor en el momento de su creación, en lugar de mantener una referencia a la variable.

Esto evita mutaciones inesperadas y carreras de datos. Por ejemplo:

var counter = 0
let closure = { print(counter) }
counter = 99
closure() // imprime 99, no 0

Si se captura por valor pasa lo siguiente:

var counter = 0
let closure = { [counter] in print(counter) }
counter = 99
closure() // imprime 0 — trabaja con su propia copia

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Sendable y Tipos-por-referencia

GoyesDev — Sat, 04 Apr 2026 16:18:51 +0000

Preguntas

¿Qué es un tipo por referencia y en qué se diferencia fundamentalmente de un tipo por valor?

Un tipo por referencia es una instancia que se manipula a través de punteros. Esto implica que cuando se modifica el valor a través un puntero, puede haber otro apuntando a la misma dirección de memoria que se vea "afectado".

Los siguientes son tipos de dato por referencia:

Clases (class)
Closures ((Input) -> (Output))
Actores (actor)
Metatipos (MyStruct.Type)
Protocolos con restricción a class o AnyObject (protocol P: AnyObject { })
NSObject
Referencias de tipo UnsafePointer & Unmanaged

¿Por qué las clases no pueden conformarse a `Sendable` tan fácilmente como las estructuras?

Puedo tener dos punteros apuntando a la misma dirección de memoria, y usar cada puntero desde un hilo diferente. En este caso podría haber un "data-race", si ambos hilos tratan de leer y modificar la misma posición de memoria simultáneamente.

¿Qué condiciones debe cumplir una clase para poder marcarse como Sendable?

// ❌ Non-final class 'Counter' cannot conform to 'Sendable'; use '@unchecked Sendable'
class Counter: Sendable {
  // ❌ Stored property 'value' of 'Sendable'-conforming class 'Counter' is mutable
  var value: Int = 0
}

Hay dos problemas en la clase anterior:

No es final.
Tiene un atributo mutable.

El atributo mutable es un problema múltiples dominios de aislamiento potencialmente podrían tener acceso y modificar la misma dirección de memoria, con lo que se generaría un data-race.

Para que una clase sea Sendable, esta debe:

Ser final.
Solo contener propiedades inmutables y Sendable.
No ser sub-class, o únicamente sub-class de NSObject.

Cualquier otro caso (no ser final, ser subclase, o tener propiedades mutables) también puede ser @unchecked Sendable, y debe tener acceso sincronizado vía NSLocking.

Convertir `class` en `actor`

Otra alternativa puede ser tener un actor, que automáticamente hace que el tipo de dato sea Sendable, gracias a que los datos se sincronizan a través del executor del actor.

Sin embargo, esto complica mucho la implementación cuando se quiere usar el actor en un contexto de concurrencia sin aislamiento:

actor X {
  var value: Int = 0
}

struct XTests {
  @Test
  func execute() {
    let sut1 = X()
    let sut2 = sut1

    // ❌ Actor-isolated property 'value' can not be mutated from a nonisolated context
    sut2.value += 1
    // ⚠️ Un actor es un dato por referencia
    #expect(sut1.value == 1)
    // ❌ Actor-isolated property 'value' can not be referenced from a nonisolated context
  }
}

Antes de convertir la clase en actor, vale la pena preguntarse:

¿Este class puede ser un struct mejor?
¿Este class necesita ser mutable y no-final?
¿Este class va a ser modificado desde distintos dominios de aislamiento? ¿O basta con marcarlo con @MainActor?

¿Por qué las clases no finales (non-`final`) no pueden ser `Sendable`?

A pesar de que tenga una súper-clase que cumpla con las condiciones para ser Sendable, el día de mañana podría aparecer una sub-clase que (1) agregue un atributo mutable o que (2) no sea Sendable. En ese caso, el compilador ya no puede asegurar que no haya data-races. Si luego se referencian unas subclases no-Sendable a través de la interfaz de la super-clase (por polimorfismo) que supuéstamente es Sendable, entonces estaría incumpliendo con el contrato.

Técnicamente se podría re-compilar todo el proyecto revisando todas las subclases; sin embargo, esto impactaría las optimizaciones de compilación.

¿Cuál es la única superclase permitida en una clase `Sendable`, y por qué?

Solo se permite heredar de NSObject al conformar Sendable, porque puede haber protocolos de APIs basadas en Obj-C, que conforman NSObjectProtocol, que requieren heredar de NSObject.

¿Cómo puede la composición ayudar a crear tipos por referencia que sean `Sendable`?

Puede ser que nuestro API ya tenga un tipo de dato class que sea Sendable y nosotros necesitemos agregarle comportamiento. En este caso, debemos buscar añadirlo por composición.

Lectura, recitación y repaso

¿Qué alternativas existen antes de convertir una clase en un actor para resolver problemas de concurrencia?

¿La clase puede ser struct?
¿Necesita ser mutable? ¿Puede ser final?

¿Por qué el compilador no puede simplemente validar todos los casos de uso de una clase no final para determinar si es segura como `Sendable`?

Se pierden optimizaciones de compilación.

¿En qué situación tendría sentido usar `@MainActor` en lugar de convertir una clase en actor?

Convertir una clase en actor provocaría que tenga que acceder con await a los datos desde contextos de concurrencia sin aislamiento.

En ciertos escenarios sabemos que vamos a modificar la clase solo desde el hilo principal, así que podemos marcarla solo con @MainActor.

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Sendable y Tipos-por-valor

GoyesDev — Sat, 04 Apr 2026 14:49:19 +0000

Preguntas

¿Qué son los value types en Swift y cómo se diferencian de los reference types?

Una instancia de un "value-type" mantiene una única copia de sus datos. Cuando se asigna a una variable o se pasa a una función, se crea una copia.

Por otro lado, una sola instancia de un "reference-type" puede ser referenciada por varios punteros. Al asignarse a una variable o pasarse a una función, se pasa una referencia a la misma posición de memoria.

¿Cuándo un `struct` o `enum` recibe conformidad implícita a `Sendable`?

struct o enum que no sea public y no esté marcado con @usableFromInline.
struct o enum congeladas ("frozen"), incluso si son públicas.

La siguiente struct es Sendable por defecto:

// ✅ Conforma Sendable por implícitamente
struct Person {
  var name: String
}

Si se la hace public deja de serlo:

// ❌ NO es Sendable de forma implícita
public struct Person {
  var name: String
}

Debido a que Swift oculta los detalles internos (como las variables privadas) de los tipos de datos públicos, el compilador es incapaz de verificar automáticamente que sea "thread-safe". Para curarse en salud, obliga al desarrollador a conformar Sendable de forma explícita.

¿Cómo influye `@usableFromInline` en la conformidad implícita de `Sendable`?

Cuando el compilador puede garantizar que un struct exista solo dentro de un módulo específico (i.e. no es public), entonces "regala" un Sendable implícito. En caso contrario, el desarrollador debe decidir explícitamente si conforma Sendable o no.

Lo anterior se debe hacer para tener una especie de "contrato" con los clientes del API:

Si el compilador infiere Sendable implícito en un struct public y luego el tipo de dato cambia, el contrato se rompe en los clientes que ya lo usaban como Sendable.
Al obligar al desarrollador a conformar Sendable de forma explícita, si el día de mañana el tipo de dato cambia, el compilador primero se estalla al compilar el API.

Ahora bien, @usableFromInline le permite a otros módulos clientes usar el tipo de dato dentro del código @inlinable. Cuando un código se hace de tipo "inline", el cliente copia el código fuente en tiempo de compilación. Si al principio se usaba el tipo de dato como Sendable y luego cambia, entonces se rompería el contrato en los clientes.

¿Por qué los `enums` públicos no marcados como `@frozen` no son implícitamente `Sendable`?

Cuando un struct o enum es marcado como public, el compilador no lo puede marcar implícitamente como Sendable porque no puede garantizar que el día de mañana se le agregue un miembro que no sea Sendable y rompa el contrato. Por esta razón, el desarrollador debe marcar el tipo de dato con Sendable de forma explícita para que el compilador pueda analizarlo.

Sin embargo, cuando un struct o enum es marcado con @frozen, el desarrollador está asegurando que la interfaz del tipo de dato no va a cambiar en el futuro. En este caso, el compilador puede marcarlo como Sendable de forma implícita, si los miembros también son Sendable.

El "Modelo de Evolución de Bibliotecas" ("Library Evolution Model") permite al cliente de una biblioteca cargar una nueva versión de la biblioteca sin necesidad de recompilar otra vez el módulo.

Los enums son el caso más delicado. Supongamos que construimos una biblioteca v1, con un enum:

public enum Resultado {
  case exito(String)
  case error(String)
}

Se puede compilar el siguiente cliente contra la biblioteca v1 y todo funciona.

// ✅ El compilador está satisfecho porque se cubren todos los casos
switch resultado {
  case .exito(let result):
    // ...
  case .error(let error):
    // ...
}

Meses después, hago el siguiente cambio en Resultado y lanzo v2:

public enum Resultado {
  case exito(String)
  case error(String)
  case pendiente // ⚠️ Nuevo caso
}

En tiempo de ejecución el cliente carga v2 y de repente el switch encuentra .pendiente, un caso que no existe en el binario compilado. Esto es un comportamiento indefinido.

Marcar el enum como @frozen asegura que el contrato público nunca va a cambiar.

La relación entre @frozen y Sendable es que cuando se tiene un enum cuyos miembros iniciales son Sendable, pero no está marcado como @frozen, el compilador no puede asegurar que el día de mañana aparezca un nuevo caso que no sea Sendable.

Por ejemplo, el día de mañana podríamos tener una nueva propiedad pendiente1 que envuelva una instancia de tipo MiClase que no es Sendable:

class MiClase {
  var contador = 0 // ❌ Las clases son no-Sendable por defecto
}

public enum Resultado {
  case exito(String)
  case error(String)
  case pendiente1(MiClase) // ⚠️ Nuevo caso no-Sendable
}

¿Qué significa que todos los miembros de un tipo deben ser `Sendable`?

Si un tipo de dato es Sendable, todos los atributos deben ser Sendable también. Si pongo uno que no lo sea, el compilador sacará el error:

Stored property ‘x_instance‘ of ‘Sendable’-conforming struct ‘Y’ has non-sendable type ‘X’

¿Cuáles son las alternativas si un miembro no puede ser marcado como `Sendable`?

Si tenemos una dependencia que no puede ser marcada como Sendable porque posiblemente es un tercero que no podemos modificar, entonces podríamos usar una de las siguientes alternativas:

Marcar el tipo de dato que estamos definiendo como @unchecked Sendable.
Revisar cómo se se está usando la dependencia para tener una referencia indirecta a ella.

Por ejemplo, en el siguiente caso, Location no es Sendable. Sin embargo, podemos tener una referencia a un Location por medio de su nombre:

public struct Person: Sendable {
  var name: String
  var hometown: String

  init(name: String, hometown: Location) {
    self.name = name
    self.hometown = hometown.name
  }
}

public struct Location {
  var name: String
}

¿Cómo se puede usar un actor para hacer un tipo `Sendable`?

Un actor es un guardan que serializa el acceso a su estado. Solo permite que una tarea a la vez acceda a sus datos.

public struct Location {
  var name: String  // ❌ String público sin @frozen, no es Sendable implícito
}

struct LocationDetailViewModel {
  let location: Location  // ❌ contiene un tipo no-Sendable
}

LocationDetailViewModel no puede ser Sendable porque Location tampoco lo es y Swift no puede garantizar que sea seguro compartirlo entre hilos.

Si todo el acceso a LocationDetailViewModel está garantizado que ocurre en el mismo actor, entonces nunca habrá dos hilos accediendo simultáneamente. El actor es el mecanismo de sincronización.

Por lo tanto, Swift puede inferir Sendable automáticamente - no porque el contenido sea seguro por sí solo, sino porque el acceso está controlado.

¿Qué es `@MainActor` y cómo simplifica la conformidad a `Sendable`?

@MainActor asegura que el código se accede únicamente a través del hilo principal y es útil para componentes como Views o ViewModels.

@MainActor se encarga de la sincronización de los hilos, asegurando el acceso a un dato. Como Swift está satisfecho de que no habrá data-races con el tipo de dato marcado con @MainActor, entonces le otorga Sendable implícitamente.

Recitar

Describe el concepto de copy-on-write (COW)

"Copy-on-write" es una optimización de rendimiento que usa Swift para colecciones de tipo por valor.

Teóricamente, los tipos por valor se copian al asignarse:

let a = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
let b = a // ⚠️ Teóricamente se copia pero, ¿y en la práctica?

Si cada asignación copiara el contenido real, trabajar con colecciones grandes sería muy costoso. Por esta razón, en lugar de copiar inmediatamente, Swift hace que a y b apunten al mismo buffer en memoria. La copia real ocurre solo cuando uno de los dos intenta modificar el contenido:

var a = [1, 2, 3]
var b = a // 😱 mismo buffer, sin copia aún

b.append(4) // ✅ aquí ocurre la copia real
            // ahora b tiene su propio buffer

Antes del append, ambos comparten memoria. En el momento de la mutación, Swift detecta que hay más de un dueño y hace la copia. Internamente, Swift usa un conteo de referencias sobre el buffer interno y, antes de mutar, pregunta: ¿Soy el único dueño de este buffer? Si la respuesta es afirmativa: muto directamente sin copiar. Si la respuesta es negativa: copio primero y luego muto.

CoW da:

Semántica de valor: a y b se comportan como copias independientes.
Rendimiento de referencia: no se paga el costo de la copia hasta que realmente se necesita.

En muchos casos no se paga el costo de la copia - Por ejemplo, si se pasa un arreglo a una función que solo lo lee, jamás se copia.

¿Por qué Swift requiere conformidad explícita a `Sendable` para tipos públicos?

Los clientes de mi API van a asumir que cierto tipo de dato es Sendable. Si el día de mañana agrego un miembro que NO es Sendable, entonces mi API va a cambiar y mis clientes ya no podrán compilar. Por esta razón, yo debo declarar explícitamente que mi tipo de dato es Sendable cuando lo hago public.

Repaso

¿Cuál es la diferencia entre un `struct` implícitamente `Sendable` y uno explícitamente `Sendable`?

¿Por qué `@frozen` permite conformidad implícita a Sendable para tipos públicos?

Resumen: ¿Cuáles son los tres mecanismos principales para garantizar que un tipo sea `Sendable`?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Conformar el protocolo Sendable

GoyesDev — Fri, 03 Apr 2026 12:38:15 +0000

Preguntas guía

¿Qué garantiza el protocolo `Sendable` al compilador sobre un tipo?

Sendable es un tipo de dato que le dice a un compilador que es "thread-safe", y se puede transmitir entre dominios de aislamiento de forma segura (sin introducir un "data-race").

¿Por qué una clase no-final no puede conformar `Sendable` de forma directa?

Una clase no-final puede tener sub-clases que introduzcan cambios inseguros, por lo que no se puede asegurar que sea "thread-safe".

Así mismo, a pesar de que una clase no-final pueda ser inmutable o tener miembros Sendable, puede ser que una sub-clase agregue miembros que no sean Sendable.

Se puede usar @unchecked Sendable en clases no-finales, sin embargo, esto implica que el desarrollador debe garantizar que la clase es "thread-safe", incluyendo a todas las sub-clases - Debido al inmenso y delicado trabajo que esto representa, no es recomendable.

¿Qué condición debe cumplirse para que una propiedad `var` en una clase sea compatible con `Sendable`?

Para que una propiedad var sea compatible con Sendable, debe ser modificada con un "lock".

¿Qué entidades de Swift se pueden marcar como `Sendable`?

Tipos-por-referencia y clases finales sin estado mutable.
Tipos-por-referencia y clases finales que manejan el acceso a su estado internamente (con "locks").
Tipos-por-valor como struct o enum.
Funciones o closures marcadas con @Sendable.

¿Por qué la conformancia a `Sendable` debe declararse en el mismo archivo fuente donde se define el tipo?

Sendable necesita ver todas las propiedades almacenadas para verificar que cierto tipo de dato puede ser transmitido de forma segura entre dominios de datos.

Compresión profunda

¿Qué diferencia hay entre `Sendable` y `@unchecked Sendable`, y cuándo se justifica usar el segundo?

Sendable significa que se garantiza que un tipo de dato es seguro para transmitirse entre dominios de aislamiento.

Conformar Sendable solamente, es una especie de contrato que indica que el compilador garantiza que el dato es "thread-safe". Por otro lado, usar @unchecked Sendable implica que el dato es "thread-safe", pero que no es garantizado por el compilador, sino por el desarrollador.

Se justifica usar @unchecked Sendable en una clase no-final, con miembros mutables por medio de "locks".

¿Cómo afecta el hecho de que una clase sea un reference type a su elegibilidad para `Sendable`?

Debido a que un objeto es reference-type, este puede ser modificado desde varios hilos. Si tiene miembros mutables, entonces no se puede garantizar que sea seguro para transmitirse entre dominios de aislamiento. Por esta razón, en caso de ser Sendable, debe ponerse @unchecked para indicar que es el desarrollador quien asegura que es seguro y no el compilador.

Por otro lado, los miembros mutables deben ser modificados a través de "locks" e, idealmente, la clase debería ser final.

Retención

Sin releer el artículo, ¿puedes enumerar al menos cuatro tipos de entidades Swift que pueden marcarse como `Sendable`?

Funciones y closures marcados con @Sendable.
Tipos de valor struct y enum.
Tipos de referencia (no-final y final) con datos inmutables o protegidos con locks.

¿Qué problema concreto introduce un `var` no protegido en una clase que intenta conformar `Sendable`?

La variable puede ser modificada desde varios hilos simultáneamente.

Evaluación crítica

¿Por qué el artículo desaconseja el uso de `@unchecked Sendable` y qué alternativas propone?

El artículo propone usar composición, clases finales o value-types.

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Condición de carrera vs. Carrera de datos

GoyesDev — Wed, 18 Mar 2026 15:20:05 +0000

1. ¿De qué trata el artículo en términos generales?

"data race", "race condition", el uso de actores para evitar "data race", cómo SC no es capaz de resolver "race condition".

2. ¿Cuáles son los dos conceptos principales que se comparan?

carrera de acceso a datos ("data race") vs condición de carrera ("race condition")

3. ¿Qué es exactamente un data race y bajo qué condiciones ocurre?

Una carrera de acceso a datos ocurre cuando varios hilos tratan de acceder a una porción de memoria compartida sin la sincronización adecuada, donde al menos uno de ellos provoca una mutación.

En el artículo aparece el siguiente ejemplo. Aunque teóricamente entiendo cómo puede fallar, en la práctica no logré obtener una carrera de datos.

nonisolated class DataRaceDemonstrator {

  func demonstrate(_ result: @escaping (Int) -> ()) {
    var counter = 0
    let queue = DispatchQueue.global(qos: .background)

    for _ in 1...10 {
      queue.async {
        // ⚠️ Mutation of captured var 'counter' in
        // concurrently-executing code
        counter += 1
      }
    }

    DispatchQueue.main.asyncAfter(deadline: .now() + 2) {
      result(counter)
    }
  }
}

Por un momento Xcode me mostró la siguiente advertencia que podría ser útil para detectar una carrera de datos:

Mutation of captured var 'counter' in concurrently-executing code

Según el artículo, se puede validar que hay una carrera de datos al activar el "Thread Sanitizer" en las herramientas de diagnóstico en "Edit Schemes".

Es muy difícil detectar una carrera de datos porque:

Determinar que hace falta sincronización es difícil. Depende de la experiencia del desarrollador.
El código inseguro no necesariamente falla en producción.
Las fallas en runtime son difíciles de reproducir.

Escribí la siguiente prueba automatizada para probar el código de arriba:

struct DataRaceDemonstratorTests {

  @Test
  func exec() async {
    let sut = DataRaceDemonstrator()

    let result = await withCheckedContinuation { continuation in
      sut.demonstrate { result in
        continuation.resume(returning: result)
      }
    }

    #expect(result == 10)
  }
}

La solución que plantea el artículo es cambiar la cola global concurrente por una serial. Sin embargo, todavía tiene la desventaja de que se deben acceder a los datos con serialQueue.async:

// let queue = DispatchQueue.global(qos: .background)
let serialQueue = DispatchQueue(label: "com.example.serial")
// ...
serialQueue.async {
  counter += 1
}

4. ¿Qué es una race condition y en qué se diferencia de un data race?

Un data race ocurre cuando múltiples hilos tratan de acceder a una porción de memoria compartida y al menos uno de ellos está modificando, sin ningún tipo de sincronización. Es un problema de sincronización de acceso.

Un race condition ocurre cuando el resultado del programa depende del orden de ejecución de las tareas y ese orden no se puede garantizar. Es un problema de orden de ejecución.

5. ¿Cómo resuelve Swift Concurrency los data races y cuáles son sus limitaciones?

Para evitar un data race se puede restringir el acceso a los datos por medio de un actor.

El ejemplo anterior se puede cambiar así:

actor Counter {
  private var value = 0
  func increment() {
    value += 1
  }
  func getValue() -> Int {
    value
  }
}

nonisolated struct DataRaceDemonstrator {

  func demonstrate() async -> Int {
    let counter = Counter()
    for _ in 1...10 {
      await counter.increment()
    }

    return await counter.getValue()
  }
}

struct DataRaceDemonstratorTests {

  @Test
  func exec() async {
    let sut = DataRaceDemonstrator()
    let result = await sut.demonstrate()
    #expect(result == 10)
  }
}

Para acceder a los datos del dominio de aislamiento del actor Counter desde cualquier otro dominio de aislamiento, sí o sí se debe usar await.

6. ¿Por qué los data races son difíciles de detectar y reproducir?

Es muy difícil detectar una carrera de datos porque:

Determinar que hace falta sincronización es difícil. Depende de la experiencia del desarrollador.
El código inseguro no necesariamente falla en producción.
Las fallas en runtime son difíciles de reproducir.

7. ¿Qué ventaja ofrece un actor sobre una serial queue de GCD?

Al usar la cola serial de GCD, igual hay que recordar leer y modificar los datos con serialQueue.async, mientras que el actor te obliga a usar await.

8. Según el artículo, ¿por qué el primer ejemplo de código con `DispatchQueue.global` es problemático aunque parezca correcto?

La operación counter += 1 no es atómica: Implica leer el valor, sumarle uno y escribirlo de nuevo. Como se usa una cola concurrente, entonces múltiples hilos podrían estar ejecutando la operación simultáneamente. Si un hilo está leyendo un valor antes de que otro haya terminado de escribir, se puede corromper el sistema.

Lo más peligroso es que el código no garantiza fallar en tiempo de ejecución, lo que lo hace muy difícil de detectar y reproducir.

9. ¿Por qué la versión con `Task` dentro del bucle sigue teniendo problemas a pesar de usar un `actor`?

El actor resuelve el problema de quieen accede al dato, pero no controla cuándo terminan las tareas. Cada Task se lanza de forma independiente y asíncrona. Cuando se ejecuta la línea final counter.getValue() no hay ninguna garantía de que las 10 tareas hayan completado sus incrementos.

El actor cumple su función (no hay dos escrituras simultáneas) pero el orden y la finalización de las tareas queda indefinido.

Recite

¿Puedes explicar con tus propias palabras la diferencia entre un data race y una race condition?

"data race" es un problema de sincronización de hilos a la hora de acceder a una región de memoria, donde al menos uno está modificándola.

Un "race condition" es un problema que aparece cuando el resultado del programa depende del orden de ejecución de las tareas, y este no puede garantizarse.

¿Qué garantiza el uso de await al acceder a propiedades de un actor?

Usar await en actor garantiza sincronización en el accedo a un dato. Esto resuelve el problema de "data race", pero no "race condition".

Review

¿Swift Concurrency resuelve completamente los problemas de concurrencia? ¿Por qué sí o por qué no?

Resuelve el problema de "data race", pero no "race condition".

¿Qué es el protocolo Sendable y cuál es su relación con los conceptos explicados en el artículo?

Sendable es un tipo de dato que garantiza acceso seguro a su estado. Al usarlo se le dice al compilador que es seguro acceder a estos valores desde cualquier dominio de aislamiento.

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Sendable

GoyesDev — Mon, 16 Mar 2026 20:42:16 +0000

¿Qué diferencia hay entre pasar valores entre hilos en GCD versus en Swift Concurrency?

Igual que en GCD, en Swift Concurrency (SC) va a ser necesario pasar un dato de un hilo a otro. Sin embargo, en SC no se trabaja con hilos sino con "Dominios de Aislamiento" (del inglés "isolation domains").

Al pasar un dato de una función async a otra, se podría estar transfiriendo información entre dos dominios de aislamiento, para lo cual, SC necesita que el dato sea de tipo Sendable para garantizar que sea "thread-safe".

¿Por qué el compilador necesita saber si un valor es thread-safe?

¿Qué es un isolation domain y para qué sirve?

Un Dominio de Aislamiento ("Isolation Domain") define una frontera en la que se puede acceder a un valor o referencia sin el riesgo de tener una carrera de datos.

Hay tres tipos de dominio:

nonisolated.
actor.
Global-actor.

¿Qué restricciones tiene el código `nonisolated` respecto al estado de otros dominios?

nonisolated es el "Dominio de Aislamiento" por defecto que no tiene restricciones de concurrencia. El código nonisolated:

Puede modificar sin problema el estado de otro código del mismo tipo.
NO puede modificar el estado de otros Dominios de Aislamiento.

El siguiente método no tiene estado y por eso se puede llamar con seguridad desde cualquier hilo:

// ⚠️ Como nonisolated es el dominio de aislamiento por defecto, es redundante ponerlo.
nonisolated func add(a: Int, b: Int) -> Int {
  a + b
}
func add(a: Int, b: Int) -> Int {
  a + b
}

¿Por qué acceder a propiedades de un actor desde afuera requiere `await`?

Un actor es un dominio de aislamiento que asegura que todas sus propiedades almacenadas y métodos se ejecutan en un ambiente seguro de un solo hilo, evitando carreras de datos.

Para acceder a los datos almacenados en un actor, se debe usar await para garantizar el acceso correcto. Básicamente sería como esperar hasta que el actor entregue o termine de modificar los datos.

// ⚠️ Se define la estructura de datos como "actor"
actor Library {

  // ⚠️ No se puede acceder directamente a books. Se puede leer
  // usando await, pero no escribir. Es ideal marcarlo private
  var books: [String] = []

  // ⚠️ Notar que los métodos no tienen async. Sin embargo, 
  // al estar definidos dentro del actor, están dentro de su
  // dominio de aislamiento y deben ser accedidos con await
  // desde otro dominio.
  func addBook(_ title: String) {
    books.append(title)
  }
  func getBookList() -> [String] {
    return books
  }

  // ⚠️ Un actor también puede tener métodos nonisolated. 
  // En este caso, para retornar un String escalar que puede
  // se accedido desde cualquier lado SIN await
  nonisolated func libraryName() -> String {
    "A library of books"
  }
}

let library = Library()

// ⚠️ No se puede invocar un método del actor, fuera de este,
// de forma síncrona.
x.addBook("hola")
// ❌ Call to actor-isolated instance method 'addBook' in a synchronous main actor-isolated context. Calls to instance method 'addBook' from outside of its actor context are implicitly asynchronous

Task {
  await library.addBook("Dopamine Nation")
  // ⚠️ Se debe llamar el método con await
  let books = await library.getBookList()
  print(books)
  // Imprime: ["Dopamine Nation"]

  // ⚠️ Se puede leer books con await
  await library.books.forEach { print($0) }
  // Imprime: ["Dopamine Nation"]

  // ⚠️ No se puede escribir books fuera del actor
  x.books.append("Dopamine Nation")
  // ❌ Error en Swift 6: Actor-isolated property 'books' can not be mutated from the main actor. Consider declaring an isolated method on 'Library' to perform the mutation
}

¿En qué se diferencia un global actor como `@MainActor` de un actor regular?

Mientras que un actor crea un dominio de aislamiento en una sola instancia, un global actor es un dominio de aislamiento compartido por varios tipos de datos, propiedades y funciones. Esto es útil cuando varias partes de la aplicación necesitan funcionar bajo las mismas restricciones.

¿Qué condiciones debe cumplir una API pública para considerarse thread-safe ("seguro entre hilos") según el protocolo `Sendable`?

El protocolo Sendable indica que cierta interfaz es thread-safe para el compilador. Se considera que una interfaz es segura para usar entre dominios de aislamiento cuando:

No hay modificadores públicos.
Cuenta con un sistema de bloqueo interno (e.g. proteger la escritura de un valor con ayuda de NSLock).
Los modificadores implementan copy-on-write como los tipos de valor.

Muchos tipos de datos de la biblioteca estándar de Swift ya tienen soporte del protocolo Sendable. Luego, el compilador puede hacer que algunos tipos de datos también tengan soporte automático de Sendable:

Por ejemplo, dado que Int: Sendable:

// ✅ SomeStruct conforma implícitamente Sendable
struct SomeStruct {
  var someIntValue: Int
}

// ❌ SomeClass NO conforma implícitamente Sendable
class SomeClass {
  var someIntValue: Int = 0
}

Recite

¿Por qué un struct con una propiedad Int conforma Sendable implícitamente, pero una class con la misma propiedad no?

Porque class es un tipo por referencia, lo que implica que puede ser modificado desde dos dominios de aislamiento diferentes.

¿Puedes explicar con tus propias palabras qué ocurre cuando un valor viaja entre dos dominios de aislamiento?

Swift debe garantizar que el valor puede trasladarse desde un dominio a otro sin el riesgo de una carrera de datos.

¿Cuándo tendría sentido marcar un método como nonisolated dentro de un actor?

Se puede marcar con nonisolated si no es necesario proteger el estado del actor. Esto ocurre, por ejemplo, si el método retorna algún valor escalar o constante.

Review

¿Cuáles son las tres condiciones bajo las cuales una API pública es segura para usarse entre dominios de concurrencia?
¿Qué cambia en Swift 6.2 respecto al comportamiento por defecto de Sendable?

Se introduce nonisolated(nonsending) que permite que las funciones y closures no sean Sendable a no ser de que atraviesen una frontera de aislamiento.

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

DEV Community: GoyesDev

[SC] Actores globales

Preguntas

¿En qué se diferencia un actor global de un actor regular?

¿A qué se parece un actor global conceptualmente, y en qué se diferencia de ese concepto?

¿A qué elementos del código se puede aplicar un actor global?

¿Por qué el estado global es peligroso en programas concurrentes y cómo lo resuelven los actores globales?

¿Qué atributo se usa para definir un actor global personalizado y qué protocolo debe conformar?

¿Qué propiedad es obligatoria para conformar al protocolo GlobalActor?

¿Qué problema introduce no tener un inicializador privado en un actor global?

¿Por qué se recomienda usar private init() en un actor global y qué previene?

¿Cómo se usa un actor global personalizado una vez definido?

¿En qué se parece al uso de @MainActor?

¿Qué ventaja tiene aislar todo el procesamiento de imágenes bajo un mismo actor global?

Recitar

¿Qué tres tipos de elementos del código puede anotar un actor global?

¿Qué pasa si alguien llama ImageProcessing() directamente sin el inicializador privado?

¿Por qué @MainActor es considerado un actor global?

Revisión

¿Cuál es la diferencia entre un actor regular y uno global en cuanto a su alcance?

¿Qué garantía en tiempo de compilación ofrece un actor global?

¿Qué requisito mínimo debe cumplir un tipo para conformar a GlobalActor?

¿Qué consecuencia tendría tener dos instancias del actor ImageProcessing en ejecución?

Bibliografía

[SC] Actores en Swift

Preguntas

¿Qué es un actor en Swift Concurrency y en qué se diferencia de una clase?

¿Qué garantía fundamental ofrece el aislamiento de actores (actor isolation)?

¿Por qué no puedes mutar directamente una propiedad de un actor desde fuera de él, aunque no sea private?

¿Qué es un executor y cuál es su función dentro de un actor?

¿En qué se diferencia el executor de un actor de una DispatchQueue serial?

¿Por qué siempre debes usar await para acceder a propiedades o métodos de un actor?

¿Cuál es la diferencia entre leer y mutar una propiedad de un actor desde fuera?

¿Por qué los actores no soportan herencia y qué implica eso en la práctica?

¿Cuál es la única excepción a la regla de no herencia en actores, y para qué sirve?

¿Qué analogía usa el artículo para describir el acceso a un actor y por qué es adecuada?

Recitar

¿Cómo serializa el acceso un actor internamente?

¿Qué error produce el compilador si intentas mutar balance directamente?

¿Qué hace un actor cuando uno de sus métodos llega a un await?

Revisión

¿En qué se parece y en qué se diferencia un actor de una clase?

¿Qué problema resuelve el actor que no resolvía NSLock automáticamente?

¿Por qué el executor de un actor sí puede ser reentrante y una DispatchQueue serial no?

Si un actor es un tipo referencia, ¿cómo garantiza igualmente la seguridad de datos?

Bibliografía

[SC] Combinando Sendable con Locks personalizados

Q — Questions (Preguntas)

¿Qué es un mecanismo de bloqueo (lock) y para qué se usa en concurrencia?

¿Cómo protege NSLock el acceso a datos mutables compartidos en la clase BankAccount?

¿Por qué el ejemplo de BankAccount es útil para entender los actores más adelante?

¿En qué situaciones conviene usar @unchecked Sendable en lugar de refactorizar a un actor?

¿Qué implica técnicamente migrar una clase con locks a un actor en Swift?

¿Cuáles son las desventajas de migrar de inmediato a un actor en una base de código existente?

¿Cuándo se recomienda usar Mutex en lugar de NSLock o actores?

R — Recite (Recitar)

¿Cómo funciona el flujo de bloqueo/desbloqueo en BankAccount?

¿Qué garantiza @unchecked Sendable y qué responsabilidad transfiere al desarrollador?

¿Qué cambia en el código que consume BankAccount cuando se migra a actor?

R — Review (Revisión)

¿Cuál es la diferencia entre una clase con NSLock y un actor en términos de acceso concurrente?

¿Por qué @unchecked Sendable es una solución temporal y no definitiva?

¿Qué acción concreta recomienda el autor para no olvidar la deuda técnica al usar @unchecked Sendable?

¿Qué factores debes considerar antes de decidir si migrar a un actor de inmediato?

Bibliografía

[SC] Valores globales seguros para concurrencia

Preguntas

¿Qué es una variable global y por qué su uso implica riesgos en contextos de concurrencia?

¿Qué error genera el compilador de Swift 6 cuando una variable global es mutable y no está aislada?

¿Cuáles son las tres estrategias principales para hacer una variable global segura para la concurrencia?

1. Aislar el acceso a la clase con un actor global como @MainActor.

2. Conformar Sendable

3. Marcar el tipo como Sendable y la propiedad mutable como nonisolated(unsafe)

¿Cuándo y por qué se usaría nonisolated(unsafe) en lugar de las otras soluciones?

¿Qué condiciones debe cumplir una clase para conformar al protocolo Sendable?

Lectura

¿Por qué aislar una clase con @MainActor puede ser problemático en algunos casos?

¿Qué papel juega private(set) cuando se usa junto con nonisolated(unsafe)?

¿En qué se parece nonisolated(unsafe) al uso de @unchecked Sendable?

Revisión

¿Qué propiedad es obligatoria para conformar al protocolo `GlobalActor`?

¿Por qué se recomienda usar `private init()` en un actor global y qué previene?

¿En qué se parece al uso de `@MainActor`?

¿Qué pasa si alguien llama `ImageProcessing()` directamente sin el inicializador privado?

¿Por qué `@MainActor` es considerado un actor global?

¿Qué requisito mínimo debe cumplir un tipo para conformar a `GlobalActor`?

¿Qué consecuencia tendría tener dos instancias del actor `ImageProcessing` en ejecución?

¿Qué es un `actor` en Swift Concurrency y en qué se diferencia de una clase?

¿En qué se diferencia el executor de un actor de una `DispatchQueue` serial?

¿Por qué siempre debes usar `await` para acceder a propiedades o métodos de un actor?

¿Qué hace un actor cuando uno de sus métodos llega a un `await`?

¿Por qué el executor de un actor sí puede ser reentrante y una `DispatchQueue` serial no?

Si un `actor` es un tipo referencia, ¿cómo garantiza igualmente la seguridad de datos?

¿Qué es un mecanismo de bloqueo (`lock`) y para qué se usa en concurrencia?

¿Cómo protege `NSLock` el acceso a datos mutables compartidos en la clase `BankAccount`?

¿Por qué el ejemplo de `BankAccount` es útil para entender los actores más adelante?

¿En qué situaciones conviene usar `@unchecked Sendable` en lugar de refactorizar a un actor?

¿Cuándo se recomienda usar `Mutex` en lugar de `NSLock` o actores?

¿Cómo funciona el flujo de bloqueo/desbloqueo en `BankAccount`?

¿Qué garantiza `@unchecked Sendable` y qué responsabilidad transfiere al desarrollador?

¿Qué cambia en el código que consume `BankAccount` cuando se migra a actor?

¿Cuál es la diferencia entre una clase con `NSLock` y un actor en términos de acceso concurrente?

¿Por qué `@unchecked Sendable` es una solución temporal y no definitiva?

¿Qué acción concreta recomienda el autor para no olvidar la deuda técnica al usar `@unchecked Sendable`?

1. Aislar el acceso a la clase con un actor global como `@MainActor`.

2. Conformar `Sendable`

3. Marcar el tipo como `Sendable` y la propiedad mutable como nonisolated(unsafe)

¿Cuándo y por qué se usaría `nonisolated(unsafe)` en lugar de las otras soluciones?

¿Qué condiciones debe cumplir una clase para conformar al protocolo `Sendable`?

¿Por qué aislar una clase con `@MainActor` puede ser problemático en algunos casos?

¿Qué papel juega `private(set)` cuando se usa junto con `nonisolated(unsafe)`?

¿En qué se parece `nonisolated(unsafe)` al uso de `@unchecked Sendable`?

¿Puedes describir de memoria los pasos para convertir `ImageCache` en una clase segura para la concurrencia?

¿Qué riesgos asumes al marcar una variable como `nonisolated(unsafe)`, y cómo podrías mitigarlos?

¿En qué situaciones el compilador ignora errores de tipos no-`Sendable`?

¿Qué problema resuelve la palabra clave `sending`?

¿Cuál es la diferencia entre usar `sending` en parámetros y en valores de retorno?

¿Por qué un tipo no-`Sendable` dentro de un método local no genera error al pasarse a una `Task`?

¿Qué ocurre si accedes a un valor después de haberlo transferido con `sending`?

¿Por qué agregar un `print` después de la transferencia rompe la compilación?

¿En qué casos concretos usarías `sending` en lugar de conformar un tipo a `Sendable`?

¿Cómo reduce el aislamiento basado en regiones la necesidad de usar `Sendable`?

¿Qué significa exactamente `@unchecked Sendable` y en qué se diferencia de `Sendable` normal?

¿En qué situaciones es apropiado usar `@unchecked Sendable`?

¿Qué riesgos concretos introduce el uso de `@unchecked Sendable`?

¿Por qué el compilador no puede verificar la seguridad de hilos cuando se usa un `DispatchQueue` como `lock`?

¿Cuál es la alternativa recomendada a `@unchecked Sendable` y por qué es superior?

¿Puedes explicar con tus propias palabras qué ocurre si se accede a `articleTitles` sin pasar por `cacheMutatingLock`?

¿Qué ventaja ofrece usar un `actor` frente a un `lock` manual?

¿En qué escenario específico el artículo acepta `@unchecked Sendable` como solución válida, y qué condición impone para usarlo?

Si tuvieras que migrar `ArticleTitlesCache` a un `actor`, ¿qué cambios estructurales serían necesarios?

¿Por qué no basta con el protocolo `Sendable` para funciones y closures?

¿Qué garantía ofrece `@Sendable` al compilador sobre los valores capturados?

4. Código `nonisolated` que delega trabajo a un actor

¿Qué diferencia hay entre capturar una variable `let` y una `var` dentro de un closure `@Sendable`?

¿Qué errores de compilación aparecen si se pasa un closure entre dominios de aislamiento sin marcarlo como `@Sendable`?

¿Cómo cambia el comportamiento del compilador al agregar `@Sendable` al parámetro `shouldBeRemoved`?

¿Por qué las clases no pueden conformarse a `Sendable` tan fácilmente como las estructuras?

Convertir `class` en `actor`

¿Por qué las clases no finales (non-`final`) no pueden ser `Sendable`?

¿Cuál es la única superclase permitida en una clase `Sendable`, y por qué?

¿Cómo puede la composición ayudar a crear tipos por referencia que sean `Sendable`?

¿Por qué el compilador no puede simplemente validar todos los casos de uso de una clase no final para determinar si es segura como `Sendable`?

¿En qué situación tendría sentido usar `@MainActor` en lugar de convertir una clase en actor?