You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A continuación se muestran los errores más comunes de la actividad AC04, es importante que lo tengan en consideración porque esto les será muy útil más adelante, en particular, para su Tarea 2. Es importante que repasen el uso de eventos y locks, ya que fue donde hubo más fallas en ésta actividad.
Un consejo general para actividades y tareas, deténganse a leer bien los tips que entrega el enunciado y reconozcan bien cuando es necesario que el programa se detenga por un cierto tiempo (esto les será particularmente útil en la T02).
Como siempre, si tienen alguna duda respecto a cualquier cosa expuesta aquí, ¡No duden en preguntarla en esta o en una nueva issue! 😄
A continuación se detallan los errores generales y específicos que observamos en la actividad.
Errores Generales:
En general faltó hacer uso de locks, hubo personas que en el método avanzar se les olvidó utilizar un lock y solo sumaban metros a los totales avanzados. Esto podría generar errores de concurrencia, ya que dos excavadores o más intentaban modificar casi al mismo tiempo un mismo valor o recurso con dos threads distintos. Lo mismo ocurrió con imprimir dinero, ya que no usaban el lockberlin. Es importante que recuerden utilizar locks en las situaciones que lo ameriten y poder sincronizar threads, así se ahorran comportamiento extraño no deseado.
Es importante que se fijen cuando es necesario usar funciones como reloj, que se les dio en esta actividad, ya que había partes en que la usaban cuando no era necesario y les faltaba usarla en partes que sí. Particularmente eran las partes que dicen “es necesario esperar X segundos/minutos” o “cierta actividad toma X segundos/minutos”.
Ojo con el uso de with al momento de ocupar locks; hubo muchos que utilizaban lock.release(), sin embargo, al usar with esto se hace automáticamente al salir del contexto que crea.
Pongan atención a los hints del enunciado y a los módulos importados en el código que se les entrega, en este caso en particular, algunos calcularon las probabilidades de ciertos eventos de manera incorrecta. Recuerden que random es capaz de entregar un elemento pseudo-aleatorio lo que les permite hacer if random.random() <= probabilidad_evento para simular la ocurrencia de eventos con cierta probabilidad.
Errores específicos de la actividad:
Algunos usaron while True dentro de la función run de excavadores, lo que causaba que su programa no terminará. Como recomendación, traten de evadir usar while True a toda costa, a menos que sepan que la función no debe parar hasta el final del programa completo. Siempre es necesario que conozcan cuál es la condición de vida del thread y la escriban dentro del while, para que termine apenas salga de este estado. En esta actividad esta condición era que los metros avanzados fueran mayores que el largo del túnel, o en su defecto, que la señal de túnel terminado fuera emitida.
En relación con el punto anterior, hubo personas que no utilizaron ningún ciclo dentro de la función run. El problema con esto es que los threads solo ejecutan el método run una vez y cuando run termina, también termina el thread. Es por esto que se debía ocupar iteración dentro de cada excavador e impresor, pues en caso contrario efectuarán sus tareas solo una vez.
Algunos definieron locks para dinero y avance del túnel como atributo de instancia, es decir dentro del init, en lugar de definirlos como atributo de clase. El problema con esto es que esto crea un nuevo lock por cada thread por cual, al no ser un lock compartido, nunca se bloquea el acceso a la sección crítica. En cambio, si se define el lock como atributo de clase, un mismo lock será compartido por todas las instancias, lo cual permite que funcione correctamente. Tanto eventos como locks son mecanismos de sincronización mediante recursos compartidos, por lo que es vital que se compartan las instancias de estos recursos. Lo mismo se aplica para el uso de señales en GUI.
Al momento de imprimir el tiempo, en algunos casos se imprimió el “tiempo actual” (time.time()) en lugar del tiempo de la simulación, la manera correcta de obtener el tiempo que tomó la simulación es guardar el tiempo actual al inicio de la simulación para luego restarlo con el tiempo del final de la simulación.
Nuevamente les recordamos, cualquier duda que tengan, pueden preguntarla en esta o en una nueva issue 😄
The text was updated successfully, but these errors were encountered:
Resumen:
A continuación se muestran los errores más comunes de la actividad AC04, es importante que lo tengan en consideración porque esto les será muy útil más adelante, en particular, para su Tarea 2. Es importante que repasen el uso de eventos y locks, ya que fue donde hubo más fallas en ésta actividad.
Un consejo general para actividades y tareas, deténganse a leer bien los tips que entrega el enunciado y reconozcan bien cuando es necesario que el programa se detenga por un cierto tiempo (esto les será particularmente útil en la T02).
Como siempre, si tienen alguna duda respecto a cualquier cosa expuesta aquí, ¡No duden en preguntarla en esta o en una nueva issue! 😄
A continuación se detallan los errores generales y específicos que observamos en la actividad.
Errores Generales:
En general faltó hacer uso de locks, hubo personas que en el método avanzar se les olvidó utilizar un lock y solo sumaban metros a los totales avanzados. Esto podría generar errores de concurrencia, ya que dos excavadores o más intentaban modificar casi al mismo tiempo un mismo valor o recurso con dos threads distintos. Lo mismo ocurrió con imprimir dinero, ya que no usaban el lock
berlin
. Es importante que recuerden utilizar locks en las situaciones que lo ameriten y poder sincronizar threads, así se ahorran comportamiento extraño no deseado.Es importante que se fijen cuando es necesario usar funciones como
reloj
, que se les dio en esta actividad, ya que había partes en que la usaban cuando no era necesario y les faltaba usarla en partes que sí. Particularmente eran las partes que dicen “es necesario esperar X segundos/minutos” o “cierta actividad toma X segundos/minutos”.Ojo con el uso de
with
al momento de ocupar locks; hubo muchos que utilizabanlock.release()
, sin embargo, al usarwith
esto se hace automáticamente al salir del contexto que crea.Pongan atención a los hints del enunciado y a los módulos importados en el código que se les entrega, en este caso en particular, algunos calcularon las probabilidades de ciertos eventos de manera incorrecta. Recuerden que
random
es capaz de entregar un elemento pseudo-aleatorio lo que les permite hacerif random.random() <= probabilidad_evento
para simular la ocurrencia de eventos con cierta probabilidad.Errores específicos de la actividad:
Algunos usaron
while True
dentro de la funciónrun
de excavadores, lo que causaba que su programa no terminará. Como recomendación, traten de evadir usarwhile True
a toda costa, a menos que sepan que la función no debe parar hasta el final del programa completo. Siempre es necesario que conozcan cuál es la condición de vida del thread y la escriban dentro delwhile
, para que termine apenas salga de este estado. En esta actividad esta condición era que los metros avanzados fueran mayores que el largo del túnel, o en su defecto, que la señal de túnel terminado fuera emitida.En relación con el punto anterior, hubo personas que no utilizaron ningún ciclo dentro de la función
run
. El problema con esto es que los threads solo ejecutan el métodorun
una vez y cuandorun
termina, también termina el thread. Es por esto que se debía ocupar iteración dentro de cada excavador e impresor, pues en caso contrario efectuarán sus tareas solo una vez.Algunos definieron locks para dinero y avance del túnel como atributo de instancia, es decir dentro del
init
, en lugar de definirlos como atributo de clase. El problema con esto es que esto crea un nuevo lock por cada thread por cual, al no ser un lock compartido, nunca se bloquea el acceso a la sección crítica. En cambio, si se define el lock como atributo de clase, un mismo lock será compartido por todas las instancias, lo cual permite que funcione correctamente. Tanto eventos como locks son mecanismos de sincronización mediante recursos compartidos, por lo que es vital que se compartan las instancias de estos recursos. Lo mismo se aplica para el uso de señales en GUI.Al momento de imprimir el tiempo, en algunos casos se imprimió el “tiempo actual” (
time.time()
) en lugar del tiempo de la simulación, la manera correcta de obtener el tiempo que tomó la simulación es guardar el tiempo actual al inicio de la simulación para luego restarlo con el tiempo del final de la simulación.Nuevamente les recordamos, cualquier duda que tengan, pueden preguntarla en esta o en una nueva issue 😄
The text was updated successfully, but these errors were encountered: