Should objects in share mem regions be volatile?

Should an object placed in an IPC shared-mem region be declared volatile, to alert the compiler that the object's internal values could change at any time?  Or would that be useless unless the internal values themselves are declared volatile?

I have an object stored in a shared memory region.  I use placement new to build the object there.  Should I declare it volatile?
chsalviaAsked:
Who is Participating?
 
jkrConnect With a Mentor Commented:
I would not place any objects in a shared memory area at all in the 1st place., but that's a different thing. Yes, it would be a good idea to declare them as volatile to tell the compiler not to use them in optimizations. It would be even better to synchronize access to these objects, though.
0
 
chsalviaAuthor Commented:
>>I would not place any objects in a shared memory area at all in the 1st place

Why?  I realize there is a danger if the object contains a pointer to another memory area, but if the object is completely self-contained, what's the harm?

>> It would be even better to synchronize access to these objects, though.

But how would multiple processes be able to share the object, without shared mem?  I suppose each process could have a unique object, which uses a file to construct itself.  But that would be much slower than just using shared mem.

0
 
jkrCommented:
Syncing access is something different, you have to take care that the data is not altered at the same time by different processes.
0
All Courses

From novice to tech pro — start learning today.