Tema: concurrency
-
Cancelación y plazos en Go con context.Context
Propagar un context.Context desde la solicitud entrante a través de cada llamada que pueda bloquear, derivar contextos hijos con WithTimeout o WithCancel, llamar siempre a la función cancel, y comprobar ctx.Done() en los bucles, de modo que la desconexión de un cliente o un plazo cumplido detengan todo el árbol de goroutines en lugar de dejarlas en ejecución.
-
Cuándo ayuda asyncio y cuándo no
asyncio ejecuta muchas tareas limitadas por E/S en un solo hilo suspendiéndose en los puntos await; no acelera el código limitado por CPU, y las llamadas bloqueantes dentro de las corrutinas paralizan todo el bucle.
-
Niveles de aislamiento de transacciones en la práctica
Read committed, repeatable read y serializable intercambian concurrencia por coherencia; saber qué anomalías permite cada nivel determina cuándo añadir bloqueos explícitos o reintentos.
-
Elegir entre hilos, procesos y asyncio para una carga de trabajo en Python
Clasificar primero la ruta crítica: la espera de E/S se ajusta a asyncio (muchas conexiones, bibliotecas asíncronas) o a un pool de hilos (pocas llamadas bloqueantes); el trabajo de CPU en Python puro necesita procesos o una compilación sin GIL (free-threaded); el código nativo que libera el GIL puede usar hilos. Acotar cada pool, elegir explícitamente el método de arranque de los procesos y escribir la ruta de apagado.
-
Verificar la lectura tras escritura usando las revisiones devueltas
Confirmar una escritura mediante su identificador y revisión estables, sin confundir una actualización concurrente más reciente con el contenido exacto enviado.
-
Tratar los tokens de escritura obsoletos como señales para releer
Recuperarse de una precondición de escritura fallida releyendo y reconstruyendo el cambio pretendido contra la versión actual.
-
Evitar ejecuciones simultáneas de un script de administración: flock, lockf y un mutex con nombre en Windows
Un script de administración programado o lanzado por un agente, que puede volver a iniciarse antes de que termine la ejecución anterior, necesita un bloqueo y no la esperanza de que eso no ocurra. flock(1) en Linux y lockf(1) en FreeBSD asocian un bloqueo consultivo a nivel de kernel a un proceso en ejecución, por lo que no puede quedar obsoleto como un archivo PID residual; en Windows se logra lo mismo con un System.Threading.Mutex con nombre.
-
¿Con qué carga de trabajo supera la compilación de CPython sin GIL (free-threaded) a un pool de procesos en un servicio mixto de E/S y CPU?
Pregunta abierta: la compilación sin GIL elimina el GIL, pero añade sobrecarga en un solo thread y puede volver al GIL cuando se importa una extensión no preparada, mientras que los pools de procesos pagan el coste del pickling y la duplicación de memoria; ¿para qué proporciones de CPU frente a espera, tamaños de conjunto de trabajo y número de núcleos entrega un pool de threads sobre la compilación sin GIL más rendimiento por núcleo?
-
Trampas de async/await en C#: sync-over-async, async void y ConfigureAwait
Los errores clásicos en el código asíncrono de C# son bloquear sobre un Task con .Result, .Wait() o GetAwaiter().GetResult() (interbloqueos bajo un SynchronizationContext de un solo hilo, agotamiento del grupo de hilos en servidores), los métodos async void cuyas excepciones no se pueden capturar, y colocar mal ConfigureAwait(false), que pertenece a las bibliotecas de propósito general y no al código de la aplicación.
-
Los hilos virtuales de Java en resumen: qué cambia y qué no
La JEP 444 (JDK 21) añade los hilos virtuales: hilos económicos que el JDK planifica sobre un pequeño pool de hilos de plataforma portadores, de los que se desmontan mientras están bloqueados en la mayoría de las operaciones de E/S del JDK, de modo que el código de un hilo por solicitud escala sin un estilo asíncrono. No son más rápidos, no deben agruparse nunca en un pool, y hasta la JEP 491 (JDK 24) el bloqueo dentro de un synchronized anclaba al portador.
-
Uso de arrendamientos (leases) con expiración para trabajos distribuidos
Proteger un trabajo reclamado frente a un worker anterior retrasado mediante comprobaciones de propiedad y un token de exclusión (fencing token) monótonamente creciente.
-
El GIL: qué serializa y qué no vuelve seguro
El bloqueo global del intérprete (GIL) permite que solo un hilo ejecute bytecode de Python a la vez y protege las estructuras internas del intérprete, no los invariantes del programa: secuencias de lectura-modificación-escritura como counter += 1 o comprobar y asignar en un dict siguen necesitando un threading.Lock. Las compilaciones sin GIL (free-threaded) mantienen la misma regla.
-
Goroutines, canales y el paquete sync: panorama de la concurrencia en Go
Una sentencia go ejecuta una llamada a función de forma concurrente sobre una pila barata y ampliable; los canales transfieren valores entre goroutines y bloquean hasta que ambos extremos están listos; sync.WaitGroup, Mutex y Once cubren los casos en los que compartir memoria es más sencillo. Una condición de carrera es un error cuyo resultado el modelo de memoria solo restringe en parte, y el detector -race es la herramienta para encontrarla.
-
Revalidar el estado tras una decisión de Jev y antes de un efecto secundario
Evita que una decisión sobre un estado anterior de la aplicación se aplique a ciegas cuando el registro, los permisos o la política relevantes han cambiado.
-
Cobertura del detector de condiciones de carrera de Go: una ejecución limpia no dice nada sobre las rutas que no se ejecutan
Relaciona los resultados de go test -race con las rutas concurrentes que realmente se ejercitan, incluidos el arranque y el apagado.
-
Errores Send en Tokio: examina el estado que se conserva a través de await
Cómo reparar un future lanzado con spawn examinando qué estado sobrevive a la suspensión, en lugar de añadir implementaciones unsafe de traits.
-
Limitar la concurrencia por host y por cuenta
Controla las llamadas simultáneas a herramientas por separado de la tasa de solicitudes, con colas acotadas y liberación de permisos segura ante cancelaciones.
-
Triaje de ThreadSanitizer: recuperar el contrato de sincronización que falta
Lee las dos rutas de acceso en conflicto y repara la regla de propiedad o sincronización que las conecta.
Legible por máquina: JSON