¿Debo bloquear el objeto cuando leo de él?

Question

Estoy escribiendo un programa en el que hay un objeto compartido por múltiples hilos:

• A) hilos de escritura múltiples escribir en el objeto (todos corriendo la misma función )
• b) un hilo de lectura que accede el objeto cada 5 segundos
• C) un hilo que tiene acceso al objeto hay una petición del usuario leer

evidentemente, es necesario bloquear el objeto al escribir en él, ya que no queremos varios subprocesos para w rito al objeto al mismo tiempo.

Mis preguntas son:

1. ¿Es también necesario bloquear el objeto cuando se lee de ella?
2. ¿Tengo razón al pensar que si solo bloqueamos el objeto al escribir, basta con una sección crítica; pero si bloqueamos el objeto al leer o escribir, ¿es necesario un mutex?

Estoy haciendo esta pregunta porque en Microsoft Office, no es posible que dos instancias de Word accedan a un documento en modo de acceso de lectura/escritura; pero mientras se abre el documento en modo de lectura/escritura, es posible abrir otra instancia de Word para acceder al documento en modo de solo lectura. ¿Se aplicaría la misma lógica en el enhebrado?

Answer 1

Como ya se escribió Ofir - si se intenta leer datos de un objeto que algún otro flujo se modyfying - se puede obtener datos en un estado incoherente.

Pero, si está seguro de que el objeto no se está modificando, puede leerlo desde múltiples hilos. En general, la pregunta que hace es más o menos el problema Lectores-escritores: consulte http://en.wikipedia.org/wiki/Readers-writers_problem

Por último, una sección crítica es un término abstracto y puede implementarse utilizando un mutex o un monitor. El azúcar de sintaxis para una sección crítica en java o C# (sincronización, bloqueo) usa un monitor debajo de las cubiertas.

Answer 2

Es necesario, porque de lo contrario (a menos que las operaciones sean atómicas) es posible que esté leyendo un estado intermedio.

Es posible que desee permitir varios lectores al mismo tiempo, lo que requiere un tipo de bloqueo (un poco) más complejo.

Answer 3

¿También es necesario bloquear el objeto al leerlo?

Si algo más pudiera escribirle al mismo tiempo, sí. Si solo pudiera ocurrir otra lectura, no. En tus circunstancias, yo diría que sí.

Estoy en lo cierto al pensar que si solo bloqueamos el objeto al escribir, una sección crítica de es suficiente; pero si cerramos el objeto al leer escribiendo, ¿es necesario un mutex?

No, puede utilizar una sección crítica para que, en igualdad de condiciones. Los mutexes tienen características añadidas sobre las secciones (los mutexes con nombre se pueden usar de múltiples procesos, por ejemplo), pero no creo que necesite esas características aquí.

Answer 4

1. depende de cómo lo use y lo lea. si su lectura es atómica (es decir, no será interrumpida por escritura) y el hilo de lectura no tiene dependencia con los hilos de escritura, entonces es posible que pueda omitir el bloqueo de lectura. Pero si su operación de "lectura" toma algo de tiempo y requiere una intensa interacción de objetos, entonces debe bloquearla para que sea leída.

2. si su lectura no lleva mucho tiempo (es decir, no retrasará demasiado los hilos de escritura), la sección crítica debería ser suficiente.

Answer 5

bloqueo solo es necesario cuando dos procesos pueden cambiar los mismos elementos de la tabla de la base de datos. cuando quiera leer datos, siempre es seguro. lees datos de una base de datos consistente. el proceso que cambia los datos tiene una versión oculta que es consistente y anulará los datos actuales cuando los guarde. pero si está ejecutando un proceso de lectura que depende del valor crítico de los elementos de la base de datos, debe buscar bloqueos que indiquen que esos valores pueden ser alterados. entonces su lectura se retrasa hasta que el bloqueo se haya ido.