/* Page prose (es) */
"WrappingUp" = "# Resumen\n\nCada error de este capítulo crece de una sola semilla: estado mutable compartido, tocado por trabajo concurrente, sin nada que coordine el acceso. Lo que hace tan peligrosa a una carrera de datos es que se esconde, así que una prueba que pasa no demuestra nada más que suerte. Las conclusiones de abajo son en realidad un solo hábito: aprender a detectar esa forma leyendo, y saber cómo cerrarla.\n\n* Una **carrera de datos** es acceso concurrente a estado mutable compartido con al menos un escritor; una **condición de carrera** es cualquier error cuyo resultado depende del momento.\n* Las carreras son **no deterministas**: normalmente correctas, a veces incorrectas, rara vez reproducibles. Las atrapas *leyendo* en busca de estado compartido-y-mutado, no ejecutando; una ejecución en verde solo demuestra que tuviste suerte esta vez.\n* `x += 1` y las actualizaciones de diccionarios/arrays son **leer-y-luego-escribir** con un hueco, no atómicas. Ese hueco es donde vive la corrupción.\n* Arréglalo coordinando el acceso: una **cola serial** (de uno en uno) o una **cola concurrente con escrituras `.barrier`** (lectores-escritores). Todo acceso a una porción de estado debe pasar por el *mismo* coordinador: ocúltalo dentro de un tipo para que quienes lo llaman no puedan saltárselo.\n* Un **interbloqueo** es una espera circular permanente. Nunca hagas `sync` sobre la cola en la que ya estás, especialmente no `DispatchQueue.main.sync` desde el hilo principal.\n* La **inversión de prioridad** es una tarea de alta prioridad bloqueada por un recurso que retiene una tarea de baja prioridad; mantén cortas las secciones críticas y no mezcles QoS muy distintas en un mismo cerrojo.\n\n---\n\n## A continuación\n\n**[Operaciones](Operations.playgroundchapter/Overview)**: envolver unidades de trabajo como objetos reutilizables que puedes nombrar, configurar, cancelar y encadenar, con `Operation` y `OperationQueue`.\n\n[Anterior](@previous)  |  página 9 de 9";
