When I do this :
myProgram.h
myProgram.c
struct PipeShm
{
// all my fields
// more
// ...
};
struct PipeShm myPipe = { /* initialization for all fields */ };
struct PipeShm * sharedPipe = &myPipe;
void func()
{
sharedPipe = mmap (NULL, sizeof * sharedPipe, PROT_READ | PROT_WRITE,MAP_SHARED | MAP_ANONYMOUS, -1, 0);
}
When I mmap
the pointer sharedPipe
, if I invoke from main()
any methods from myProgram
code, would all processes share the exact shared memory that I shared with myPipe
struct?
Or would each new child that's created, would have a new myPipe
of his own?
Regards
EDIT:
This is after I read the comments & answers : now changes were made , and I initialize the values of the segment only after I allocate it :
#include "my_pipe.h"
struct PipeShm * sharedPipe = NULL;
int shm_pipe_init()
{
if (!sharedPipe)
{
int myFd = shm_open ("/myregion", O_CREAT | O_TRUNC | O_RDWR, 0600);
if (myFd == -1)
error_out ("shm_open");
// Allocate some memory in the region - We use ftruncate, write(2) would work just as well
int retAlloc = ftruncate (myFd, sizeof * sharedPipe);
if (retAlloc < 0)
error_out("ftruncate");
sharedPipe = mmap (NULL, sizeof * sharedPipe,
PROT_READ | PROT_WRITE,MAP_SHARED | MAP_ANONYMOUS, myFd, 0);
if (!sem_init (&sharedPipe->semaphore, 1, 0))
{
sharedPipe->init = TRUE;
sharedPipe->flag = FALSE;
sharedPipe->ptr1 = NULL;
sharedPipe->ptr2 = NULL;
sharedPipe->status1 = -10;
sharedPipe->status2 = -10;
sharedPipe->semaphoreFlag = FALSE;
sharedPipe->currentPipeIndex = 0;
}
else
perror ("shm_pipe_init");
}
return 1; // always successful
}
The problem however continues ,the shared memory seems to be not so shared between the processes , since while running and forking that main :
int main()
{
int spd, pid, rb;
char buff[4096];
fork();
shm_pipe_init();
// more
return 0;
}
I still get outputs , that simulates the behavior like only one process is running (instead of multiple outputs , I get only a single one or a couple ,depends on a race condition between the processes) .
Each would have its own, since changes to the pointer
sharedPipe
do not affectmyPipe
.If you intend to call this program several times, the answer is "no". If you intend to fork after creating the mapping, the answer is "yes".
An anonymous mapping has no underlying file. Therefore, a process creating an anonymous mapping has no way of specifying which already existing mapping in particular it wants (and this is also not the intended usage, you're supposed to get a new, independent one). Therefore "no" to the first case.
A shared mapping allows all processes that own the same mapping to access the same phsyical memory. This means, if you
fork
after creating the mapping, thenfork
will mostly work the usual way, marking all pages owned by the process as copy-on-write except the pages in the mapping. Both the parent and the child will retain the mapped pages and will be able to access the same physical memory through the pointer (incidentially, this means the pages will even have the same virtual addresses, too -- this is normally not something you can rely on when mapping a file, but in this case the OS has no other choice but to make sure this is the case).The manpages remain vague about the combination of anonymous and shared mapping or about what exactly is supposed to happen, but TLPI chapter 49.7 explicitly mentions
MAP_SHARED|MAP_ANONYMOUS
:Therefore "yes" for the second case.
Re: edited post
Wrong order:
This forks first and then initializes the shared memory. Which will just create a shared (read as share-able, it may be shared in the future, if the process forks again, but it does not magically back-share with the parent!) mapping for each process, separately.
You then have two mappings, one in each process, which will be shared by their respective child and grandchild processes (if any), but which will help nothing to achieve what you want. The fact that they are "shared" does not matter, they're different mappings, and unknown to the respective other process.
First create the mapping, then fork. This will create one shared mapping that both processes indeed own/share and can use for the intended purpose.
(Besides, your usage of
fork
is not strictly wrong, but a bit weird... you're normally supposed to check the return value, so you know which one is the parent and which one is the child. And it's not likefork
can't fail. Of course if that doesn't matter at all because parent and child are always 100% identical and you don't care about failure, that's fine. Normally, one usually wants to know, though.)Let's step through what you're exactly doing here
This allocates a
PipeShm
structure as a global variableThis creates a pointer to previously created structure.
Now you're modifying the pointer
sharedPipe
to whatmmap
returns (presumably an address to a region of shared memory) instead of the structure you allocated before (note:myPipe
still exists - just not pointed to).As far as I can see, you've also made no attempts to access
sharedPipe
. So now, you basically have a global variable and a section of shared memory (both of which appear unused).This is where I'm not so sure what you're trying to do.
If you want to access the shared memory, you'll need to dereference the
sharedPipe
pointer aftermmap
returns (if so, what was the point of the global variable?).If you want to access the global variable, just access it as
myPipe
(if so, what wasmmap
for?).If you want to access both, then use a combination of the above (if so, what was the point of doing
struct PipeShm * sharedPipe = &myPipe;
?)