- Inicio
- Habilidades
- Revision de Codigo
- Revision de Concurrencia
Revision de Concurrencia
Revisa codigo concurrente: race conditions, deadlocks, seguridad de hilos, operaciones atomicas y estado compartido.
El Problema
Los bugs de concurrencia son la clase mas dificil de defectos de software. Aparecen intermitentemente, desaparecen durante el debugging, y dependen de timing que no se puede reproducir confiablemente. Una race condition en un sistema de pagos procesa un cargo dos veces. Un cache compartido sin bloqueo adecuado retorna datos desactualizados. Un deadlock congela el servidor a las 3 AM bajo carga pico. Estos bugs sobreviven las pruebas porque requieren interleaving especifico.
El Prompt
Revisa el siguiente codigo por problemas de concurrencia. Actua como un ingeniero de sistemas distribuidos analizando codigo bajo acceso concurrente.
LENGUAJE/RUNTIME: [ej. Node.js (single-threaded + async), Go (goroutines), Java (threads)]
MODELO DE CONCURRENCIA: [async/await, threads, goroutines, actors, web workers]
RECURSOS COMPARTIDOS: [ej. base de datos, cache en memoria, sistema de archivos, API externa]
CODIGO:
[pegar codigo aqui]
Analiza en estas dimensiones de concurrencia:
1. **Race Conditions**
- Las secuencias read-modify-write son atomicas?
- Dos requests/hilos pueden interleavar entre verificacion y accion (TOCTOU)?
- Se accede a variables compartidas sin sincronizacion?
2. **Deadlocks & Livelocks**
- Se adquieren multiples locks en orden inconsistente?
- Pueden formarse condiciones de espera circular?
- Hay operaciones de bloqueo indefinido sin timeouts?
3. **Correctitud Async (JS/Python)**
- Las promises se manejan correctamente (sin unhandled rejections)?
- Los closures compartidos se mutan a traves de boundaries de await?
- Los eventos pueden dispararse en orden inesperado despues de un await?
4. **Concurrencia de Base de Datos**
- Se usan transacciones para operaciones multi-paso?
- El nivel de aislamiento correcto esta configurado?
- Se usan patrones de optimistic locking (columnas de version)?
5. **Consistencia de Cache**
- Datos cacheados desactualizados pueden servirse despues de que la fuente cambie?
- Hay problema de thundering herd?
- La invalidacion de cache y actualizacion de datos son atomicas?
6. **Ciclo de Vida de Recursos**
- Las conexiones, handles de archivo y locks se liberan en todos los caminos?
- Puede ocurrir agotamiento de recursos bajo trafico en rafaga?
Para cada problema, proporciona:
- **Ubicacion**: Archivo y linea
- **Escenario**: Interleaving especifico que dispara el bug
- **Probabilidad**: Probable bajo carga / Raro pero catastrofico / Teorico
- **Impacto**: Corrupcion de datos / Procesamiento doble / Deadlock / Datos obsoletos
- **Fix**: Codigo de reemplazo seguro para concurrencia
Ejemplo de Salida
## Revision de Concurrencia: 3 problemas encontrados
### Probable Bajo Carga: Race Condition de Doble Cargo
Ubicacion: src/services/payment.ts:15
Codigo:
const balance = await getBalance(userId); // T1 lee $100
if (balance >= amount) { // T1 verifica: 100 >= 80 ✓
await deductBalance(userId, amount); // T2 tambien lee $100, tambien pasa
} // Resultado: $100 - $80 - $80 = -$60
Fix (optimistic locking):
const result = await db.query(
"UPDATE balances SET amount = amount - $1 WHERE user_id = $2 AND amount >= $1 RETURNING amount",
[amount, userId]
);
if (result.rowCount === 0) throw new InsufficientBalance();
Cuando Usar
Ejecutar en cualquier codigo que maneje requests concurrentes (servidores web, consumidores de cola, jobs de fondo), estado compartido (caches, contadores, balances), o transacciones de BD con multiples tablas. Esencial antes de deployar codigo que procesa pagos o maneja inventario.
Tips Pro
- Describir el modelo de concurrencia — Node.js single-threaded async tiene riesgos fundamentalmente diferentes a Java multi-threaded.
- Pedir diagrama de timing — “Dibuja un diagrama ASCII mostrando como dos requests concurrentes pueden interleavar.”
- Pensar en transacciones — “Cual es el nivel minimo de aislamiento de transaccion para prevenir este bug?”
- Stress test mental — “Que pasa si 100 usuarios golpean este endpoint simultaneamente?”