CODEWITHSUNDEEP
c++shared-memory
Prasanth Madhavan
Prasanth Madhavan

Reputation: 13309

Shared memory C++ Read and Write synchronisation

Will the shared memory be corrupted if two programs access it simultaneously, one writing into it and the other one reading from it?

I have two programs, one will get some data from servers and web and save parsed data into the shared memory, and i have a read program, that will read until the last saved data set.

For example, if the first program has collected data from 100 servers and is currently in the 101th server, all the data until the 100th server will be read by the reader program. Once 101th is finished, then reader program will read the 101th data set. Here data set from a server may have multiple data, like disk space, load etc. So does this kind of access corrupt the data in the shared memory? Or is it ok the way i do it?

Upvotes: 0

Views: 2517

Answers (2)

LihO
LihO

Reputation: 42083

What you have described is actually a common computing problem in concurrency called Readers-writers

If you try to read from the memory while other program is writing to it, you will most likely get corrupted data. You should use one of synchronization primitives (locks, semaphores, monitors...) to ensure this situation will never happen.

I recommend you to have a look at The Little Book of Semaphores, especially chapter 4.2 Readers-writers problem.

Upvotes: 4

zmccord
zmccord

Reputation: 2612

Is there a reason you're doing this with processes instead of threads? That might make your life harder from a synchronization perspective.

If you were working with threads I would tell you to protect your accesses with a semaphore so that you can guarantee that the reader is not reading the same data set that the writer is writing; I believe that implementations of semaphores and other synchronization primitives exist for inter-process shared memory as well but that's a little less common.

The reason you should definitely be using someone else's synchronization primitives is that on modern hardware, writes can be reordered or delayed e.g. the first program is "currently in the 101st server" but in actuality the writes to the data for the 100th server are not yet written back from the CPU. A semaphore or mutex will include the appropriate memory fencing instructions to flush writes so that memory looks consistent from other threads/processes; you should absolutely use someone else's carefully written implementation rather than write your own synchronization logic.

Also, when you are testing it is very important that you test on a multiprocessor machine, as race conditions between processes are much less likely to appear on a uniprocessor box.

Upvotes: 4

Related Questions