Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback AC04 #372

Open
Drpinto1 opened this issue Oct 2, 2019 · 0 comments
Open

Feedback AC04 #372

Drpinto1 opened this issue Oct 2, 2019 · 0 comments
Assignees
Labels
actividades Issues relacionadas con las actividades del curso IMPORTANTE

Comments

@Drpinto1
Copy link
Contributor

Drpinto1 commented Oct 2, 2019

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 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 😄

@Drpinto1 Drpinto1 added IMPORTANTE actividades Issues relacionadas con las actividades del curso labels Oct 2, 2019
@Drpinto1 Drpinto1 self-assigned this Oct 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
actividades Issues relacionadas con las actividades del curso IMPORTANTE
Projects
None yet
Development

No branches or pull requests

1 participant