What will happen if I read and write in parallel in the same MemoryMappedFile? Is it necessary that I lock them via Mutext before reading as shown in the samples on MSDN?
Asked
Active
Viewed 2,396 times
3
-
How do you write to the file? The *file* itself can of course be written to concurrently, a single accessor is ["not guaranteed to be thread safe."](https://msdn.microsoft.com/en-us/library/system.io.memorymappedfiles.memorymappedviewaccessor%28v=vs.110%29.aspx) – JimmyB Jul 30 '15 at 14:34
-
I want to write from one application via `BinaryWriter` and read from another application via `BinaryReader`. – BendEg Jul 30 '15 at 14:38
-
Are you trying to use a memory mapped file as some kind of process communication? – Ron Beyer Jul 30 '15 at 14:42
-
This should definitely work. I believe the use of a `Mutex` in the example is only there to sychronize the work of the demo processes; otherwise the reading process may already have terminated before the writer got to write any data. The bare data exchange does not require synchronization, although you'll commonly want to somehow signal when data is ready to be read or written. – JimmyB Jul 30 '15 at 14:50
2 Answers
6
Each "View" created from your memory mapped file can only be accessed by a single thread at a time, however you can create multiple view streams and each thread can write or read to it at the same time.
However, if multiple views try to write to the same location at the same time you may get data "intermixed" with each other. The mutex in the example is to prevent that mixing. If one app is only writing to the file and the other is only reading then there is no need for a mutex, you only need it for multiple writers.
Scott Chamberlain
- 124,994
- 33
- 282
- 431
-
This was the needed hint: ` If one app is only writing to the file and the other is only reading then there is no need for a mutex, you only need it for multiple writers.` Thank you! – BendEg Jul 30 '15 at 21:03
1
The short answer is that you could possibly read corrupt data or write corrupt data, and you must gain exclusive access (such as the Mutex) unless the reads and writes are well timed (ugh!) or it's known they aren't hitting the same parts of the memory mapped file.
Consider a chunk of data at offset 100 that is 100 bytes long. A writer begins writing at offset 0 to 150, and another writes from 180 to 300. Your reader begins reading that 100 bytes while the writers are writing. What is read? What if another writer is writing from 180 to 300 at the same time. What is written? Likely, an interleaved chunk of corrupt data.
The classic way to solve this problem is with a reader-writer lock. In .NET, if you're doing parallel reads and writes within a single process, you could use ReaderWriterLockSlim or the older ReaderWriterLock.
If you want to do this with multiple processes, you could use FileStream.Lock() and FileStream.Unlock(). A trickier solution would be to to use a combination of a semaphore and mutex. Follow the links from this SO question for ideas.
Even in this is may not be enough. If your memory mapped file is used by a process that you don't control (e.g. a third-party), then you could get corruption. The solutions above are examples of cooperative algorithms (all the parties know what's going on and behave accordingly).
The heaviest-handed method would be to lock the entire memory mapped file upon opening using FileShare.None.
