Question

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

Answer 1

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