grupo de subprocesos, datos compartidos, Sincronización Java

Question

decir que tengo un objeto de datos:

class ValueRef { double value; }

donde cada objeto de datos se almacena en una colección maestra:

Collection<ValueRef> masterList = ...;

también tener una colección de trabajos, donde cada trabajo tiene una colección local de objetos de datos (donde cada objeto de datos también aparece en el masterList):

class Job implements Runnable { 
    Collection<ValueRef> neededValues = ...; 
    void run() { 
     double sum = 0; 
     for (ValueRef x: neededValues) sum += x; 
     System.out.println(sum); 
    } 
} 

de casos de uso:

1. for (ValueRef x: masterList) { x.value = Math.random(); }

2. rellenar una cola de trabajos con algunos puestos de trabajo.

3. despertar a un grupo de subprocesos

4. Esperar a que cada puesto de trabajo se ha evaluado

Nota: Durante la evaluación del trabajo, todos los valores son todos constantes. Sin embargo, los subprocesos posiblemente hayan evaluado trabajos en el pasado y conserven valores en caché.

Pregunta: ¿Cuál es la cantidad mínima de sincronización necesaria para garantizar que cada thread vea los últimos valores?

Entiendo la sincronización desde el monitor/lock-perspective, no entiendo sincronizar desde el cache/flush-perspective (es decir, qué está garantizado por el modelo de memoria al entrar/salir del bloque sincronizado).

Para mí, parece que debería sincronizar una vez en el hilo que actualiza los valores para asignar los nuevos valores a la memoria principal y una vez por hilo de trabajo para vaciar la caché para que se lean los nuevos valores. Pero no estoy seguro de cómo hacer esto.

Mi enfoque: crear un monitor mundial: static Object guard = new Object(); A continuación, sincronizar el guard, mientras que la actualización de la lista maestra. Finalmente, antes de iniciar el grupo de subprocesos, una vez para cada subproceso del grupo, sincronice en guard en un bloque vacío.

¿Eso realmente causa una descarga total de cualquier valor leído por ese hilo? ¿O solo los valores tocados dentro del bloque de sincronización? En cuyo caso, en lugar de un bloque vacío, ¿debería leer cada valor una vez en un ciclo?

Gracias por su tiempo.

---

Editar: Creo que mi cuestión se reduce a, una vez que sale de un bloque sincronizado, no todos los primeros de lectura (después de ese punto) ir a la memoria principal? Independientemente de en qué sincronicé?

Answer 1

No importa que los subprocesos de un grupo de subprocesos hayan evaluado algunos trabajos en el pasado.

Javadoc de Executor dice: efectos de consistencia

Memoria: Acciones en un hilo antes de presentar un objeto Ejecutable a un ejecutor suceder antes de que comience su ejecución, tal vez en otro hilo.

Por lo tanto, siempre que utilice la implementación estándar del grupo de subprocesos y cambie los datos antes de enviar los trabajos, no debe preocuparse por los efectos de visibilidad de la memoria.

Answer 2

Lo que estás planeando suena suficiente. Depende de cómo planee "activar el grupo de subprocesos".

El modelo de memoria de Java proporciona que todas las escrituras realizadas por un subproceso antes de entrar en un bloque synchronized son visibles para los subprocesos que posteriormente se sincronizan en ese bloqueo.

Por lo tanto, si está seguro de los subprocesos de trabajo se bloquean en un wait() llamada (que debe estar dentro de un bloque synchronized) durante el tiempo de actualizar la lista maestra, cuando se despiertan y se convierte en ejecutable, las modificaciones hechas por el el hilo maestro será visible para estos hilos.

Sin embargo, le recomiendo aplicar las utilidades de concurrencia de mayor nivel en el paquete java.util.concurrent. Estos serán más sólidos que su propia solución, y son un buen lugar para aprender la concurrencia antes de profundizar.

---

Solo para aclarar: Es casi imposible controlar subprocesos de trabajo sin utilizar un bloque sincronizado, donde se realiza una comprobación para ver si el trabajador tiene una tarea de implementar. Por lo tanto, cualquier cambio realizado por el hilo del controlador en el trabajo ocurre, antes de que el hilo de trabajo se despierte. Necesita un bloque synchronized, o al menos una variable volatile para actuar como barrera de memoria; sin embargo, no puedo pensar cómo crearías un grupo de subprocesos con uno de estos.

Como ejemplo de las ventajas de utilizar el paquete java.util.concurrency, considere esto: se puede utilizar un bloque de synchronized con una llamada wait() en ella, o un bucle ocupado: espere con una variable volatile. Debido a la sobrecarga de la conmutación de contexto entre subprocesos, una espera ocupada puede funcionar mejor bajo ciertas condiciones. — no es necesaria la horrible idea que uno podría asumir a primera vista.

Si utiliza las utilidades de Concurrencia (en este caso, probablemente un ExecutorService), la mejor selección para su caso particular se puede hacer para usted, teniendo en cuenta el entorno, la naturaleza de la tarea y las necesidades de otros hilos en un momento dado. Lograr ese nivel de optimización es mucho trabajo innecesario.

Answer 3

¿Por qué no haces que Collection<ValueRef> y ValueRef sean inmutables o al menos no modifiquen los valores en la colección después de haber publicado la referencia a la colección. Entonces no tendrás ninguna preocupación sobre la sincronización.

Ahí es cuando desea cambiar los valores de la colección, crear una nueva colección y poner nuevos valores en ella. Una vez que se han establecido los valores, pase la referencia de colección a los nuevos objetos de trabajo.

La única razón para no hacer esto sería si el tamaño de la colección es tan grande que apenas cabe en la memoria y no puede permitirse tener dos copias, o el intercambio de las colecciones causaría demasiado trabajo para el recolector de basura (compruebe que uno de estos es un problema antes de utilizar una estructura de datos mutable para el código de subprocesamiento).