0

I have a c++ application that keeps updating a specific block of shared memory. And I have another dotnet core application that reads from that block whenever it needs the data. Currently I am using a flag for synchronization, whenever c++ application starts updating, it sets the flag as true and sets to false after it's done. Dotnet core application checks whether the flag is false or not before reading. But I think there is some issue in this method. Is there some other way of doing this?

TheBlaDe
  • 45
  • 5
  • Yeah, use a shared mutex. – paddy Feb 15 '21 at 07:57
  • FYI: [SO: c++11 interprocess atomics and mutexes](https://stackoverflow.com/a/19908903/7478597) Btw. Boost.Interprocess has a complete sub-chapter about [Synchronization mechanisms](https://www.boost.org/doc/libs/1_75_0/doc/html/interprocess/synchronization_mechanisms.html). – Scheff's Cat Feb 15 '21 at 08:25

1 Answers1

0

Yes, it's called "mutex." Which essentialy means you "lock" a resource, and only give it free when you are done with it. Ensuring that other applications can't change the variable/data, which in turn prevents some forms of race conditions. The combination of a flag and mutex is often used. Mutex a variable during reading and writing, and setting flags when that operation is done. Mutexing while reading ensures the data is not read halfway through a write operation as writing is not possible and vice versa, causing damage (race condition). There are tons of other ways as well. Google "multi-threading resource management" or "concurrency" for more information. And see wiki

Oscar K
  • 185
  • 1
  • 11
  • I thought of using named mutex/semaphore earlier, but I am currently on linux and I don't think linux supports named objects. What kind of locking can I use that works both in c++ and dotnet core on linux machine. Thanks! – TheBlaDe Feb 15 '21 at 08:06
  • I'm currently at work, but I have to do some actual work now. So if it's not answered, I'll try and get back to you. – Oscar K Feb 15 '21 at 08:06