Shared memory variables in C, extern keyword

Question

If I create shared memory variables in C, where are they placed (heap / stack / data section / ...)? I am using 64 bit Ubuntu with gcc-4.8 and the compilerflag -m32 for 32bit and this code:

segment_id = shmget (IPC_PRIVATE, shared_segment_size, 
                     IPC_CREAT | IPC_EXCL | S_IRUSR | S_IWUSR); 
shared_memory = (char*) shmat (segment_id, 0, 0); 
printf ("shared memory attached at address |%10p\n", shared_memory);

I get the following output for this:

shared memory attached at address |0xf76de000

However, valgrind gives this:

shared memory attached at address | 0x4039000

Why? Do shared variables have anything to do with the extern keyword? If another process wants to use the data, can he choose where to attach the memory?

What do you mean by "valgrind gives this"? Do you mean you ran the program through valgrind and the output was different to running without valgrind? — kaylum, Nov 19 '15 at 22:06
Yes, totally. If i start the program "as usual" like this: ./myprog it prints 0xf76de000. I have tried this on 3 different PCs. If I use valgrind like this: valgrind ./myprog it prints 0x4039000. — 今天春天, Nov 19 '15 at 22:08
It's a *virtual address*. Every process can (and is likely) to see a different virtual address. The important thing is that mapping the same shared memory segment will map to the same *physical address* (regardless of what virtual address the process sees). Related: [Where is linux shared memory actually located?](https://stackoverflow.com/questions/21325001/where-is-linux-shared-memory-actually-located) — kaylum, Nov 19 '15 at 22:09
Okay, I do understand. So I can probably map the shared data to any region, no matter whether it is the stack, heap, or the section where global variables are? — 今天春天, Nov 19 '15 at 22:11
One way to think about it is that shared memory objects are files, and each process loads the contents of the file into its own address space. The OS is then responsible for keeping each shared memory object synched. On linux systems, you can even look into /dev/shm to see them. — bruceg, Nov 19 '15 at 22:17
@今天春天 No you can't. If you specify a particular address (ie, non-NULL `shmaddr` in the `shmat` call and `SHM_REMAP` flag for Linux) then you need to be careful as it may overlap existing memory regions. But you should avoid doing that unless you really have to and know what you are doing. Just pass `NULL` for that parameter (as you are doing) and let the OS take care of which memory region to place the shared memory at. Note that all of this is covered in [the man page](http://linux.die.net/man/2/shmat) so I suggest you read that carefully if you want to understand in full. — kaylum, Nov 19 '15 at 22:17

score 2 · Accepted Answer · answered Nov 19 '15 at 22:13

Think of shared memory as process-independent (take that with a grain of salt) memory chunks that are managed by the kernel. When you call shmat(), think of it as a mmap()-like operation that creates a mapping between the address space of the current process and the shared segment. In fact, you can force the address to be a particular value with the second argument to shmat(). But if you do not, it is automatically generated. The actual value will depend on a number of factors, the current memory mapping of the process in particular.

Thus you have one mapping when you run the process standalone, and another when using valgrind. For all intents and purposes you can consider this a heap address - it is not going to be a part of your stack space. But better, just forget the stack and heap distinction and think of it as some memory you got that you can play with as long as you do it by the rules (do not overwrite the boundaries, respect permissions),

Thank you, this really helped and also explained why things like 0xf76de000 were printed because when I do mallocs the pointers also get similar addresses. Can you imagine what this could have to do with the extern-keyword in C? — 今天春天, Nov 19 '15 at 22:16
One additional thing: Do you think accessing shared variables is slower than accessing "normal" heap storage created with malloc? — 今天春天, Nov 20 '15 at 07:43

Shared memory variables in C, extern keyword

1 Answers1