Results 1 to 4 of 4
After creating new instances of my program with fork() is it possible to have some variables common to all instances. (In other words: If i change the value of a ...
- 10-27-2007 #1Just Joined!
- Join Date
- Oct 2007
- Posts
- 3
fork() and common variables (gnu C++)
After creating new instances of my program with fork() is it possible to have some variables common to all instances. (In other words: If i change the value of a variable in one instance, the same variable is updated in all other instances)
Any help would be greatly appreciated!
- 10-27-2007 #2You can do this, sort of.If i change the value of a variable in one instance, the same variable is updated in all other instances
You can't actually change variables. What you can do is have a chunk of shared memory. You map out how you use that shared memory with a struct. If you want your code to be industrial strength, you synchronize your use of that shared memory so that only one process can write to it at a time, and no process can read it while any process is writing it.
There's a bad way to do this, and a good way to do this.
The bad way is to use the SVr4 family of functions. Do this at the command line:
The reason this is the bad way is that there's a limit (not extremely large) on the total number of shared memory segments and semaphores that can exist in the system at one time, and if all your processes exit or die without removing a particular shared memory segment or semaphore, that entity stays around forever, reducing the remaining number of available shared memory segments and semaphores. "Forever" means that you can only get clean them up through special shell commands or your own specialized tools (writing those would be a waste of time, usually) or rebooting.Code:# shared memory stuff: man shmget man shmctl man shmat man shmdt # synchronization stuff: man semget man semctl man semop # if you want to get fancy: man ftok
The good way to use shared memory is to have your mothership process do something like this before the first fork(). "Something like this" means I haven't tested this particular code fragment, although I've used this technique in real life):
Then use something like area->fred to access each item.Code:#include <sys/types.h> #include <sys/mman.h> #include <fcntl.h> typedef struct { /* declare your shared data stuff here */ } shared_stuff_t, *shared_stuff_p; int fd; shared_stuff_p area; fd=open("/dev/zero", O_RDWR ); if(fd==-1) { /* put error handling stuff here */ } area=(shared_stuff_p)mmap(0, sizeof(shared_stuff_t), PROT_READ|PROT_WRITE,MAP_SHARED, fd, 0 ); if(area==(shared_stuff_p)-1) { /* put error handling stuff here */ }
To synchronize your data, use a lock file. A lock file can be any file that's guaranteed to exist and be accessible by all processes. By "accessible", I mean "I'm lazy and I don't know whether the file has to be readable and writable, but just do it that way, or run your own experiments if you're persnickety."
To use a lock file, do this at the command line:
Don't be lazy by using flock(); it's better to keep your program POSIX compatible as much as possible.Code:man fcntl
The advantage of this second way is that the shared memory segment remains present until the final process using it goes exits or blows up (at which point it disappears automatically), and any given lock on the lock file remain present until until the process imposing that lock either removes the lock, exits, or blows up (at which point the lock disappears).
And yes, there's nothing special about the mother process. If it goes away and any descendants remain, the shared memory segment and any locks (other than locks imposed by the mother process) remain.
All this (both the bad way and the good way) can be done with either C or C++.
Hope this helps.
- 10-27-2007 #3Just Joined!
- Join Date
- Oct 2007
- Posts
- 3
Thank you very much for your help!
Do you know if its possible to make a function available for several processes?
- 10-27-2007 #4
Sure. When you do a fork(), all the code that was running in the parent process is still there in the child process, unless and until the child process calls a function from the exec family.
Or did you mean something different?


Reply With Quote