Laboratorio 1: PidTable

Objetivos:
	- Solucionar problemas de "thread safety" en una clase, teniendo en cuenta y midiendo el impacto en la performance.
	- Relacionar corrección global de la teoría de Owicki-Gries con algunos problemas de concurrencia típicos (check-then-act, read-modify-write, etc.)


Actividades


Primera parte:

- Leer y entender el código.
- Revisar los asserts del código usados siguiendo los lineamientos de Programación Defensiva.
- Probar con diferentes números de hilos y ver si salta.
	. Probablemente haya que usar java -ea PidTableTest, donde ea="enable assertions".
- Agregar StoYield.yield() en puntos críticos de PidTable para generar planificaciones más ricas a fin de invalidar los asserts.
- Comentar todos los System.out.println(), esto parece producir interleavings mucho más ricos.
- Agregar un assert que se debería mantener al medio del check-then-act que aparece en PidTable.alloc(E) y ver que es efectivamente inválido cuando hay más de un hilo.


Segunda parte:

- Mantener todos los StoYield.yield() que se usaron anteriormente para lograr planificaciones interesantes.
- Comentar todos los System.out.println(), generan mucho overhead que ocultan las diferencias de performance.
	. ¿Hipótesis respecto a esto?
- Sincronizar para evitar que se invaliden los invariantes de representación y la aserción interna de check-then-act, asi como de los incrementos de las variables. Usar los siguientes 3 esquemas:
	1) Métodos sincronizados.
	2) Bloques sincronizados solo en el lugar que se necesitan.
	3) AtomicInteger para los contadores size y capacity y bloques sincronizados para las otras "condiciones de carrera".
- Por cada uno de ellos medir la performance:
	. Usar alternativamente el comando *NIX time java -ea PidTableTest > /dev/null
	. Calibrar PidTableUse.CYCLE_NUM para que la ejecución tome un tiempo significativo (2 o 3 segundos) a fin de enmascarar lo más posible el efecto de caches frías, tiempos de carga, optimizaciones runtime, etc. .