(el usuario blanco puede editar, Nico)
Dividir ejemplos en:
Investigar
javap -c desensabla bytecode. Listado de los VM Opcodes.-server en la jre optimiza más.assert para los invariantes.assert está desde JDK 1.4.2.-source 1.4 o -source 5.0 para aceptarla.java -ea, ver también -esa.volatile o con synchronized?wait.CondVar sobre todo en Java 6 y Java 5, en Java 1.4.2 no está-XX:PreBlockSpin=10 Spin count variable for use with -XX:+UseSpinning. Controls the maximum spin iterations allowed before entering operating system thread synchronization code. (Introduced in 1.4.2.) -XX:-UseSpinning Enable naive spinning on Java monitor before entering operating system thread synchronizaton code. (Relevant to 1.4.2 and 5.0 only.) [1.4.2, multi-processor Windows platforms: true]
Implementar *[ x:=x+1; x:=x-1 ] Deducir el grado de atomicidad de x:=x+1 a partir de si se cumple el invariante 0⇐x⇐2. Es notoria la diferencia entre 1 CPU y 2 CPUs en la riqueza del scheduling. Relacionar esto con el hecho de que el planificador de Java es cooperativo en realidad, o sea no tiene Quanto. Está bueno mostar:
synchronized(this) { } sincroniza con el mismo objeto thread.compareAndSwapInt que internamente usa sun.misc.Unsafe, y de esta última no encontre sourcecode javap -c y ver que el incremento está desacoplado. Notar los monitorenter, monitorexit.36: monitorenter 37: aload_0 38: getfield #15; //Field N:LMyInt; 41: dup 42: getfield #52; //Field MyInt.value:I 45: iconst_1 46: iadd 47: putfield #52; //Field MyInt.value:I 50: aload_1 51: monitorexit
Bill Pugh, produjo un ejemplo limpio del problema The "Double-Checked Locking is Broken" Declaration.
El problema es que para Java5 no saltan los errores.
java.util.concurrent.