Simultáneamente, escriba

cómo escribir en un archivo de texto al que se puede acceder por varias fuentes (posiblemente de forma simultánea) para garantizar que no se pierda ninguna operación de escritura.Simultáneamente, escriba

Como si dos procesos diferentes están escribiendo en el mismo momento en el archivo, esto puede causar problemas. La solución simple (no muy rápida y no muy elegante) sería bloquear el archivo al comenzar el proceso (crear un archivo .lock o similar) y liberarlo (eliminar el bloqueo) mientras se realiza la escritura.

Al comenzar a escribir, verificaría si el archivo .lock existe y retrasaré la escritura hasta que se lance el archivo.

¿Cuál es el patrón recomendado a seguir para este tipo de situación?

Gracias

EDIT me refiero a los procesos, como diferentes programas de diferentes clientes, diferentes usuarios y así sucesivamente, no las discusiones dentro del mismo programa

Fuente

2009-07-21 pistacchio

¿Quiere decir dos procesos o hilos diferentes? Porque si desea tener acceso seguro a un archivo para pocos procesos, no hay mucho que pueda hacer sin usar algún Mutex u otro mecanismo de bloqueo entre procesos. –

sugiere emplear la ReaderWriterLock. Está diseñado para lectores múltiples pero garantiza que solo un escritor puede escribir datos en cualquier momento MSDN.

Fuente

2009-07-21 16:22:43 Ian

No utilice ReaderWriterLock, tiene un bajo rendimiento. Utilice ReaderWriterLockSlim o uno de los bloqueos de Jeffrey Richter en la biblioteca Wintellect PowerThreading. –

No usar ninguno;). Bloqueos de ReadWriter, Monitores (bloqueos), etc.no son capaces de bloqueos entre procesos, que es lo que el autor quiso decir, creo (como, si dos procesos diferentes están escribiendo en el mismo momento en el archivo)? –

No utilice el bloqueo entre procesos. Cambie a un sistema operativo que solo ejecuta un proceso a la vez. – Kieveli

Puede intentar bloquear también. Es fácil: "el bloqueo asegura que un hilo no ingrese a una sección crítica mientras otro hilo está en la sección crítica del código. Si otro hilo intenta ingresar un código bloqueado, esperará (bloqueará) hasta que se libere el objeto".

http://msdn.microsoft.com/en-us/library/c5kehkcz%28VS.71%29.aspx

Fuente

2009-07-21 16:25:47

Creo que esto es más caro que usar un ReaderWriterLock simple ... – Ian

En realidad, usar el monitor (bloqueo) es más barato que ReaderWriterLockSlim.EnterWriteLock + ExitLock. Es genial usar rw lock, cuando tienes pocos lectores y escritores, pero en este caso, prefieres no leer desde el archivo, ya que es solo un archivo de registro, en su mayoría escribirás en él, por lo que necesitarás usar WriteLocks solo de todos modos -> por lo tanto, no podrá acceder concurrentemente al recurso -> por lo tanto, puede usar el bloqueo regular. Sin mencionar que ambos no funcionarán para la sincronización entre procesos. –

Me gustaría ver algo así como el Command Pattern para hacer esto. La escritura concurrente sería una pesadilla para la integridad de los datos.

Esencialmente utiliza este patrón para poner en cola sus comandos de escritura para que se realicen en orden de solicitud.

También debe usar el ReaderWriterLock para asegurarse de que puede leer el archivo mientras se escribe. Esta sería una segunda línea de defensa detrás del patrón de comando para que solo un hilo pueda escribir en el archivo en un momento dado.

Fuente

2009-07-21 16:26:12 joshlrogers

+1 por recomendar el uso de una cola, pero casi te pedí el comentario de RW-lock después. The Queue maneja sus propios bloqueos ... ¿qué más estás bloqueando? –

Quise decir más para una segunda línea de defensa. Lo cual a posteriori creo que hay una mejor manera de hacerlo que usar el RWL, pero odiaría tenerlo optimizado prematuramente a pesar de las caídas en el rendimiento de RWL. Sin embargo, estoy empezando a preguntarme si se refería a múltiples procesos/aplicaciones diferentes que acceden y escriben en un archivo, y de ser así, ninguno de estos dos tendría valor. – joshlrogers

Considere el uso de una base de datos simple. Obtendrá toda esta seguridad integrada relativamente fácil.

Fuente

2009-07-21 16:26:49 DanDan

La manera más rápida de sincronizar el acceso entre procesos es usar Mutexes/Semaphores. Este hilo responde cómo usarlos, para simular el patrón de bloqueo de lectura y escritura: Is there a global named reader/writer lock?

Fuente

2009-07-21 16:36:59

Hay una forma de usar un Mutex con nombre que se puede referenciar desde múltiples procesos. Si todo el acceso a los archivos proviene de un único proceso (pero múltiples hilos), todos pueden apuntar al mismo mutex para adquirir el bloqueo. – Kieveli

Kieveli: el autor significaba procesos diferentes, por lo tanto, los mutexes/semáforos son las opciones más obvias, y es por eso que escribí sobre ellos, si hablamos de hilos, funcionarían mutexes y construcciones más simples como ReadWriteLock. –

También recomendaría buscar ejemplos de tener múltiples lectores y solo 1 escritor en una sección crítica aquí hay un breve artículo con una buena solución http://arxiv.org/PS_cache/cs/pdf/0303/0303005v1.pdf

Alternativamente, podría ver crear copias del archivo cada vez que se solicita y cuando llega el momento de escribir cualquier cambio en el archivo que se fusiona con el archivo original.

Fuente

2009-07-21 16:59:51 mbehan

Respuesta

Cuestiones relacionadas