Accediendo a diferentes miembros de datos pertenecientes al mismo objeto desde 2 hilos diferentes en C++

Question

Tengo algunos objetos que necesito para realizar acciones desde diferentes hilos en C++. Sé que es necesario bloquear cualquier variable que pueda ser utilizada por más de un hilo al mismo tiempo, pero ¿qué pasa si cada hilo está accediendo (escribiendo) a un miembro de datos diferente del mismo objeto? Por ejemplo, cada hilo llama a un método diferente del objeto y ninguno de los métodos llamados modifica el mismo miembro de datos. ¿Es seguro siempre que no acceda al mismo miembro de datos o de todos modos tenga que bloquear todo el objeto?

He buscado explicaciones y detalles sobre este tema, pero cada ejemplo parece centrarse en variables individuales o funciones que no son miembros.

Resumiendo: ¿Puedo acceder con seguridad a 2 miembros de datos diferentes del mismo objeto desde 2 hilos diferentes sin colocar un bloqueo en todo el objeto?

Answer 1

Es efectivamente seguro, pero reducirá fuertemente el rendimiento de su código si lo hace con frecuencia. Las computadoras usan cosas llamadas "líneas de caché" y si dos procesadores están trabajando en la misma línea de caché tendrán que volver a pasarla & todo el tiempo, ralentizando su trabajo.

Answer 2

Sí, es seguro acceder a diferentes miembros de un objeto por hilo diferente.

Answer 3

Creo que puede hacerlo bien. Pero es mejor asegurarse de que los métodos internos nunca cambien para acceder a los mismos datos o el programa que llama no decida llamar a otro método que otro hilo ya esté usando, etc.

Tan posible, pero potencialmente peligroso. Pero también será más rápido porque evitarás llamadas para obtener mutexes. Elige tu veneno.

Answer 4

¿Es seguro siempre que no acceda al mismo miembro de datos o tengo que bloquear todo el objeto de todos modos?

La respuesta depende totalmente del diseño de la clase. Sin embargo, yo diría que siempre se recomienda pensar 100 veces antes de permitir que varios subprocesos accedan al mismo objeto. Dado el hecho, si está seguro de que los datos son realmente independientes su es NO necesita bloquear todo el objeto.

Luego surge una pregunta diferente, "Si las variables son realmente independientes ¿Por qué están en la misma clase?" Tenga cuidado al enhebrar mata si se equivoca.

Answer 5

Bueno, sí, está bien, puedes hacerlo pero, como han señalado otros, no deberías tener que hacerlo. En mi humilde opinión, el acceso a los miembros de los datos debe ser a través de métodos getter/setter para que cualquier mutexing/criticalSectioning/semaphoring/lo que sea necesario esté encapsulado dentro del objeto.

Answer 6

Es posible que desee tener cuidado. Ver por ejemplo http://gcc.gnu.org/ml/gcc/2012-02/msg00032.html Dependiendo de cómo se accede a los campos, es posible que se encuentre con problemas similares difíciles de encontrar.