multithreading - thread - ¿Necesito bloquear el objeto cuando leo?

thread python 3

Question

Estoy escribiendo un programa donde hay un objeto compartido por varios subprocesos:

• A) Varios hilos de escritura escriben en el objeto (todos ejecutando la misma función)
• B) Un hilo de lectura que accede al objeto cada 5 segundos.
• C) Un hilo de lectura que accede al objeto hay una solicitud de usuario

Obviamente, es necesario bloquear el objeto cuando se escribe en él, ya que no queremos que varios subprocesos escriban en el objeto al mismo tiempo.

Mis preguntas son:

1. ¿Es necesario también bloquear el objeto al leerlo?
2. ¿Estoy en lo cierto al pensar que si solo bloqueamos el objeto al escribir, una sección crítica es suficiente? pero si bloqueamos el objeto al leer o escribir, ¿es necesario un mutex?

Estoy haciendo esta pregunta porque en Microsoft Office, dos instancias de Word no pueden acceder a un documento en modo de acceso de lectura / escritura; pero mientras el documento se abre 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 los hilos?

Answer 1

¿Es necesario también 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 es suficiente? pero si bloqueamos el objeto al leer o escribir, ¿es necesario un mutex?

No, puede usar una sección crítica para ambas cosas, en igualdad de condiciones. Los Mutexes han agregado funciones a las secciones (por ejemplo, los nombres de Mutex se pueden usar en varios procesos), pero no creo que necesite estas funciones aquí.

Answer 2

1. Depende de cómo lo uses y lo leas. Si su lectura es atómica (es decir, no será interrumpida por escritura) y el subproceso de lectura no tiene dependencia con los subprocesos de escritura, entonces es posible que pueda omitir el bloqueo de lectura. Pero si su operación de ''lectura'' toma algún tiempo y requiere una interacción de objetos pesados, entonces debe bloquearla para leer.

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 3

Como Ofir ya escribió: si intentas leer datos de un objeto que algún otro hilo está modificando, podrías obtener datos en algún estado inconsistente.

Pero, si está seguro de que el objeto no se está modificando, por supuesto puede leerlo desde varios subprocesos. En general, la pregunta que está haciendo es más o menos el problema de los lectores-escritores: consulte http://en.wikipedia.org/wiki/Readers-writers_problem

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

Answer 4

Es necesario, porque de lo contrario (a menos que las operaciones sean atómicas) puede estar leyendo un estado intermedio.

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

Answer 5

el bloqueo solo es necesario cuando dos procesos pueden cambiar los mismos elementos de la tabla de la base de datos. Cuando quieres leer datos siempre es seguro. lees datos de una base de datos consistente. el proceso de cambio de los datos tiene una versión alternativa 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 es probable que esos valores se modifiquen. por lo que su lectura se retrasa hasta que el bloqueo se ha ido.