1. La básica de funciónamiento

Para que una simulación sea siquiera posible, el tiempo de burnout debe permitir al menos un ciclo completo de trabajo.

La condición mínima para que un coder sobreviva al menos una compilación es:

<aside> 💡

time_to_burnout > time_to_compile

</aside>

Pero, para que pueda repetir (según el requisito de compiles_required), el tiempo de burnout debe ser mayor que el tiempo que pasa "fuera" del dongle, porque el contador de muerte sigue corriendo mientras espera en la cola:

<aside> 💡

time_to_burnout >

(time_to_compile + time_to_debug + time_to_refactor + dongle_cooldown)

</aside>

Probar al límite

• number_of_coders vs dongles:
  • Si tienes number_of_coders impares y requieres 2 dongles para compilar, siempre habrá alguien esperando. Prueba con 1, 3, 5 coders. Los números impares suelen ser donde ocurren los deadlocks.
• Tiempos de trabajo muy cortos:
  • Con time_to_compile muy pequeño (ej. 1ms). Esto estresa el planificador de hilos del sistema operativo y los mutex. Si falla aquí, es que existen problemas de condiciones de carrera (Race Conditions) en el acceso a las variables compartidas.
• Tiempos de trabajo muy largos:
  • Pon tiempos muy grandes. Esto ayuda a ver si tu monitor está realmente comprobando la muerte en tiempo real o si se queda bloqueado esperando a que una función termine.

Escenarios de Pruebas

✨Escenario ideal

valgrind --leak-check=full --show-leak-kinds=all ./codexion 4 800 100 100 100 5 10 fifo

• Explicación: Con 800 ms de vida, un cooldown bajísimo de 10 ms y orden de llegada básico (fifo), los 4 coders completarán sus 5 compilaciones de forma holgada y pacífica.

🔥Burnout forzado

valgrind --leak-check=full --show-leak-kinds=all ./codexion 3 50 200 100 100 10 0 fifo

• Explicación: Un coder necesita 200 ms para compilar, pero solo tiene 50 ms de vida inicial. Nadie llegará jamás a compilar. El monitor debe detener el programa alrededor del milisegundo 50.