Ok, good one. Like in clone, I want to share memory between forked processes. I can use shared memory calls from shmat, etc. Heres the clincher.

I create CLIST * as a shmget, shmat. The fuctions that allocate memory in CLIST do not. The result is memory in data members were not shared...

Are there other ways? Id hate to convert every library I have to shared memory, simply because of fork. Theres got to be a way.

Use threads?

"Show us [a relevant snippet of ...] your code," please. Provide us with a more complete description of your situation, and of your dilemma.

As you know, "fork()" creates an entirely new process, sharing nothing with its parent but a link to the code-segment and a snapshot of the local variables. But, obviously, you know all that. So, I think we can dispense with all of those preliminaries ...

So ... why does your particular situation (whatever it is ...) prompt you to "use fork" and then to "share memory between" them? "What's coming down here, friend? Where are you stuck? What are you trying to do?" Second pair of (been-there, done-that) eyes, at your service ...

I have to admit I don't know what do you mean by CLIST. Would you mind starting your question at the very beginning, not in medias res.

CLIST is simply what it suggests. Its a dynamic allocated chain array with next pointers instead of static variables.

I want portability on any system. Including Windows. I could use the clone fuction, but this is Linux specific.

I am talking threads, but I want portability. The fuctions in Linux often vary greatly than Windows. Threads are forks, suggested by docs, but indeed copy even the dynamic allocations!

In both processes after a fork, I have the same dynamic memory address using printf. To my surprise, after fork, I change the allocated string to a new statement. Both are to print afterwords. What happens? The child fork prints the original string, while the parent prints the changed string. But wait! They both have the same memory address!

The result is that the child receives no updates from the parent. Only pipes and shmget memory can be used. Even simple malloc data is meaningless. However, what is going on that makes clone differ in regards of sharing data?

Im overall intrigued that mallocs are even copied. However, how do both have the same memory address in dynamic allocations?

it doesn't suggest nothing, although google spits out this

(p)threads in linux are made with clone() and locking is implemented with futex-es and some userspace things

Never heard the term "chain array", is it like a linked list?

You can't "share memory between forked processes" in a portable way. Windows doesn't even have the concept of "forked processes".

There is a pthreads implementation for Windows. https://www.sourceware.org/pthreads-win32/

Threads are not forks, I wonder which docs you're reading...

Virtual memory.

Where am I missing this? I thought the SHMEM utilities were exactly for this where you have separate processes versus what you get with a clone or a thread. You allocate a shared memory segment, you get an ID, that ID is what you share between processes so that they can obtain a semaphore and get ownership and then write data to the shared memory segment. This is exactly what you use it for.

This example is two separate programs, but fundamentally it's the same idea, two separate processes http://www.cs.cf.ac.uk/Dave/C/node27...00000000000000

If multiple threads (rather than multiple processes) is a better fit for your requirements, then use multiple threads.

If there is some portability issue with native threading (though that is hard to understand compared to the greater portability issues of using multiple processes) use some more portable version of multi-threading, such as OMP or Intel's (free and largely portable) TBB.

Your description is too vague for me to make a decent guess about what misconception is behind your confusion.

Memory can be explicitly shared between processes (in Linux or Windows) so changes written to memory in one process will be readable from memory in the other.

But fork must act as if it copied (rather than shared) all the private (not explicitly shared) portions of the address space. In fact fork really shares, rather than copying almost all the memory, but using a hidden "copy on write" kind of sharing. So that any time either process writes to any page (aligned 4KB chunk) of memory that has the hidden sharing, the kernel rips that sharing apart and gives the writing process its own private copy of the page.


That misconception is more obvious. You are apparently unaware about the relationship between virtual addresses and physical addresses. Every address in a process is a virtual address. Every reference to memory goes through a mapping table that converts virtual addresses to physical addresses. Each process has its own mapping table to convert virtual to physical.

On fork, those mapping tables go through the same kind of "copy on write" hidden sharing as the memory itself. As long as an aligned set of 512 pages are shared between two processes, that part of the mapping table could be shared. As soon as any one of those 512 pages is unshared (by copy on write) the page of mappings must also be unshared.

Regardless of those subtleties in fork, a virtual address in one process is not connected to the same virtual address in another process. Linux can make those two addresses map to the same place or to different places within the physical address space.

In my screen shot I have a string with "Original string" in main. I call a fuction that uses fork. The parent returns to main, the child executes recursive printfs. The parent exits first back to main. I call strcpy and set the string to "New string" wait is then called for the child. Child begins executing prints with usleep. Despite parents speed, it prints "Original string"

All string addresses point to the same one in print...

Enc

fork_source.txt

Attached Thumbnails

 

Attached Files

fork_sorce.txt (3.3 KB, 30 views)

No, they don't. Because part of an address is the PID, which specifies what address mapping to use. The PID is different between the two tines of the fork.

In your sample code all the shm* calls are commented out. Wasn't this a question of shared memory?

Child inherits copies what the parent had at fork(). Even if the addresses *look* the same, they are not. The resemblance is confusing until you understand this. Your eyebrows might look just like your dad's, but they are not your dad's eyebrows.

I'm no guru, but shared memory lives outside any process. You can close the starting process, go make tea, go to work, go on vacation, get home, open a different program 2 weeks later, and link to the shared mem chunk unless someone explicitly closed it or the PC rebooted.

1 members found this post helpful.

That was my earlier point, explained differently. I like your description.

@OP, I cited a web example, still recommend you give that a look.

IPC: Shared Memory Example two processes comunicating via shared memory: shm_server.c, shm_client.c

At some point please take the time to read the answers you already received. Otherwise, what was the point of asking the question.