4

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) .

Improve this question
3
  • what do you mean by "all processes"? All processes in the system, or all child processes of the original, etc? Commented Jul 31, 2012 at 11:07
  • 1
    @tbert: All the processes - meaning child processes , grandsons ...etc Commented Jul 31, 2012 at 11:13
  • Writing hint: There is no blank before punctuation (comma, colon, semicolon, full stop, question mark etc.) in English. Commented Jul 31, 2012 at 11:29

3 Answers 3

Reset to default
10

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, then fork 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:

[...] followed by a call to fork(), then, because the child produced by fork() inherits the mapping, both processes share the memory region.

Therefore "yes" for the second case.

Re: edited post
Wrong order:

fork(); shm_pipe_init();

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 like fork 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.)

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

3

Let's step through what you're exactly doing here

struct PipeShm myPipe = { /* initialization for all fields */ };

This allocates a PipeShm structure as a global variable

struct PipeShm * sharedPipe = &myPipe;

This creates a pointer to previously created structure.

Now you're modifying the pointer sharedPipe to what mmap 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). 

sharedPipe = mmap (NULL, sizeof * sharedPipe, PROT_READ | PROT_WRITE,MAP_SHARED | MAP_ANONYMOUS, -1, 0);

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 after mmap 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 was mmap 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;?)

Improve this answer

1 Comment

Please see the modified post , I did as you said ... you were right!
2

Each would have its own, since changes to the pointer sharedPipe do not affect myPipe.

Improve this answer

6 Comments

OK , then how can I change the above to make all processes (child-processes) to have the same memory ? thanks
They already do. In sharedPipe. You must dereference it to access the fields.
You mean that : struct PipeShm * sharedPipe = myPipe; ? if so , this is does not compile .
@ron, I would suggest you should do ..shm_open(to get a shared memory), ftruncate (set the set of the size of the memory to your structure's size) and then mmap (get the pointer, then initialise it by accessing the members of the structure). This mapped memory (that is the pointer) should be available to use for all the processes that you are referring.
@Tanmoy: Please see the modified post , I did what you suggested , however the problem still stands.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.