¿Para qué se usan las cercas de memoria en Java?

Mientras intentaba entender cómo SubmissionPublisher( código fuente en Java SE 10, OpenJDK | docs ), una nueva clase agregada a Java SE en la versión 9, se implementó, me topé con algunas llamadas a la API VarHandleque no conocía anteriormente:

fullFence` acquireFence` releaseFence, loadLoadFencey storeStoreFence.

Después de investigar un poco, especialmente con respecto al concepto de barreras / vallas de memoria (he oído hablar de ellos anteriormente, sí; pero nunca los usé, por lo que no estaba muy familiarizado con su semántica), creo que tengo una comprensión básica de lo que son . No obstante, dado que mis preguntas pueden surgir de una idea errónea, quiero asegurarme de haber acertado en primer lugar:

1. Las barreras de memoria son restricciones de reordenamiento con respecto a las operaciones de lectura y escritura.

2. Las barreras de memoria se pueden clasificar en dos categorías principales: barreras de memoria unidireccionales y bidireccionales, dependiendo de si establecen restricciones en lecturas o escrituras o en ambas.

3. C ++ admite una variedad de barreras de memoria , sin embargo, estas no coinciden con las proporcionadas por VarHandle. Sin embargo, algunas de las barreras de memoria disponibles VarHandleproporcionan efectos de ordenamiento que son compatibles con sus correspondientes barreras de memoria C ++.

   • #fullFence es compatible con atomic_thread_fence(memory_order_seq_cst)
   • #acquireFence es compatible con atomic_thread_fence(memory_order_acquire)
   • #releaseFence es compatible con atomic_thread_fence(memory_order_release)
   • #loadLoadFencey #storeStoreFenceno tiene contraparte compatible con C ++

La palabra compatible parece ser realmente importante aquí, ya que la semántica difiere claramente en lo que respecta a los detalles. Por ejemplo, todas las barreras de C ++ son bidireccionales, mientras que las barreras de Java no lo son (necesariamente).

4. La mayoría de las barreras de memoria también tienen efectos de sincronización. Esos dependen especialmente del tipo de barrera utilizada y las instrucciones de barrera ejecutadas previamente en otros hilos. Como todas las implicaciones que tiene una instrucción de barrera son específicas del hardware, me quedaré con las barreras de nivel superior (C ++). En C ++, por ejemplo, los cambios realizados antes de una instrucción de barrera de liberación son visibles para un subproceso que ejecuta una instrucción de barrera de adquisición .

¿Son correctas mis suposiciones? Si es así, mis preguntas resultantes son:

1. ¿Las barreras de memoria disponibles VarHandlecausan algún tipo de sincronización de memoria?

2. Independientemente de si causan sincronización de memoria o no, ¿para qué pueden ser útiles las restricciones de reordenamiento en Java? El modelo de memoria de Java ya ofrece algunas garantías muy sólidas con respecto a los pedidos cuando intervienen campos volátiles, bloqueos u VarHandleoperaciones similares #compareAndSet.

En caso de que esté buscando un ejemplo: lo mencionado anteriormente BufferedSubscription, una clase interna de SubmissionPublisher(fuente vinculada anteriormente), estableció una cerca completa en la línea 1079 (función growAndAdd; ya que el sitio web vinculado no admite identificadores de fragmentos, solo CTRL + F para ello ) Sin embargo, no está claro para mí para qué sirve.

Esto es principalmente una no respuesta, realmente (inicialmente quería hacer un comentario, pero como puede ver, es demasiado largo). Es solo que lo cuestioné mucho, leí e investigué mucho y en este momento puedo decir con seguridad: esto es complicado. Incluso escribí múltiples pruebas con jcstress para descubrir cómo funcionan realmente (mientras observa el código de ensamblaje generado) y aunque algunas de ellas de alguna manera tenían sentido, el tema en general no es en absoluto fácil.

Lo primero que debes entender:

La Especificación del lenguaje Java (JLS) no menciona barreras , en ningún lado. Esto, para Java, sería un detalle de implementación: realmente actúa en términos de suceder antes de la semántica. Para poder especificarlos adecuadamente de acuerdo con el JMM (Modelo de memoria de Java), el JMM tendría que cambiar bastante .

Este es un trabajo en progreso.

En segundo lugar, si realmente quieres rascar la superficie aquí, esto es lo primero que debes ver . La charla es increíble. Mi parte favorita es cuando Herb Sutter levanta sus 5 dedos y dice: "Esta es la cantidad de personas que realmente pueden trabajar correctamente con estos". Eso debería darle una pista de la complejidad involucrada. Sin embargo, hay algunos ejemplos triviales que son fáciles de entender (como un contador actualizado por múltiples subprocesos que no se preocupa por otras garantías de memoria, pero solo se preocupa de que se incremente correctamente).

Otro ejemplo es cuando (en Java) desea que una volatilebandera controle hilos para detener / iniciar. Ya sabes, lo clásico:

volatile boolean stop = false; // on thread writes, one thread reads this    

Si trabaja con Java, sabrá que sin volatile este código está roto (puede leer por qué el bloqueo de verificación doble está roto sin él, por ejemplo). ¿Pero también sabe que para algunas personas que escriben código de alto rendimiento esto es demasiado? volatileleer / escribir también garantiza una coherencia secuencial , que tiene algunas garantías sólidas y algunas personas quieren una versión más débil de esto.

¿Una bandera segura para hilos, pero no volátil? Sí, exactamente: VarHandle::set/getOpaque.

¿Y preguntarías por qué alguien podría necesitar eso, por ejemplo? No todos están interesados ​​en todos los cambios que están respaldados por a volatile.

Veamos cómo lograremos esto en Java. En primer lugar, este tipo de exóticos cosas ya existían en la API: AtomicInteger::lazySet. Esto no está especificado en el modelo de memoria Java y no tiene una definición clara ; Todavía la gente lo usó (LMAX, afaik o esto para leer más ). En mi humilde opinión, AtomicInteger::lazySetes VarHandle::releaseFence(o VarHandle::storeStoreFence).

Intentemos responder por qué alguien los necesita .

JMM tiene básicamente dos formas de acceder a un campo: simple y volátil (que garantiza la coherencia secuencial ). Todos estos métodos que mencionas están ahí para traer algo entre estos dos: semántica de liberación / adquisición ; Hay casos, supongo, donde la gente realmente necesita esto.

Una relajación aún mayor de la liberación / adquisición sería opaca , lo que todavía estoy tratando de entender completamente .

Por lo tanto, en resumen (su comprensión es bastante correcta, por cierto): si planea usar esto en Java, no tienen especificaciones por el momento, hágalo bajo su propio riesgo. Si desea comprenderlos, sus modos equivalentes de C ++ son el lugar para comenzar.