(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 . Aparentemente está en los fuentes del SDK que se bajan del sitio “developers”.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
.