ped@ahuta.UUCP (p.davidson) (04/03/85)
How do you pass a key from one process to another process so that both processes have acess to the same "shmid"? In other words how do you insure that each process has the same shared memory id?
ped@ahuta.UUCP (p.davidson) (04/03/85)
With shared memory, If the process that first created or reserved the memory exits/terminates can another process still access what ever was in that memory?
dave@uwvax.UUCP (Dave Cohrs) (04/04/85)
> How do you pass a key from one process to > another process so that both processes have acess to the > same "shmid"? > In other words how do you insure that each > process has the same shared memory id? I have implemented the SysV shared memory (well, not very well, but it works like the man pages describe) under 4.2BSD. In one application, we open up a server socket and the process with wants the same shmid connects to this and gets it. If you don't have these neat 4.2 functions, I'd suggest sending the shmid through a pipe to the other process or, if they aren't parent and child, make a famous file and put it there. dave -- dave cohrs ...!{allegra,harvard,ihnp4,seismo}!uwvax!dave dave@wisc-limburger.arpa (bug? what bug? that's a feature!)
dave@uwvax.UUCP (Dave Cohrs) (04/04/85)
> With shared memory, If the process that first created or > reserved the memory exits/terminates can another process > still access what ever was in that memory? The shared memory partition is not actually deallocated until a shmctl() is done to deallocate it. -- dave cohrs ...!{allegra,harvard,ihnp4,seismo}!uwvax!dave dave@wisc-limburger.arpa (bug? what bug? that's a feature!)
john@genrad.UUCP (John Nelson) (04/05/85)
>> With shared memory, If the process that first created or >> reserved the memory exits/terminates can another process >> still access what ever was in that memory? > >The shared memory partition is not actually deallocated until a shmctl() >is done to deallocate it. > Actually, the shared memory partition is not deallocated until a shmctl() is done to destroy it, and all the current users of that partition have released it (or terminated). Note that after the shmctl that destroys the partition, no new process can attach to that segment.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (04/06/85)
> How do you pass a key from one process to > another process so that both processes have acess to the > same "shmid"? Message passing?
tim@cithep.UucP (Tim Smith ) (04/07/85)
Shared memory stays around when the creator dies. Someone has to explicitly
ask it to go away.
As for passing the key to another proc, how about msg(2)? :-) :-) :-)
--
Duty Now for the Future
Tim Smith
ihnp4!{wlbr!callan,cithep}!timmjs@eagle.UUCP (M.J.Shannon) (04/09/85)
> > How do you pass a key from one process to > > another process so that both processes have acess to the > > same "shmid"? > > Message passing? The "proper" way to do this is to use the ftok() (stdipc(3C)) routine with a filename that all processes involved agree upon. Yes, it is difficult to find this routine (due to the name of the manual entry and the contents of the NAME section, it doesn't appear anywhere useful in the permuted index), but that's how to do it. Honest -- I've used it! -- Marty Shannon UUCP: ihnp4!eagle!mjs Phone: +1 201 522 6063
Hoffman.wbst@xerox.arpa (12/18/85)
I'm a beginner C/UNIX hack programming on an AT&T PC 7300 running UNIX System V. I have two parallel processes (one a child of the other) and I need both to have access to one linked list (essentially a queue). The scenario is as follows: --The parent process allocates and fills the first node. --The parent process invokes the child process, and then, optionally, continues building the list. --The child process extracts the necessary information from the first node and then removes that node from the head of the list, proceeding to the next node. If there is no next node, the child process goes to sleep until the parent process builds another linked list. After the child process is invoked, the parent process is only concerned with the tail of the list while the child process is only concerned with the head of the list. As I see it, there are two cases of interest: 1) The child process reaches the end of the list and goes to sleep at the same time the parent process allocates and begins filling another node. If this happens, the parent will not realize that it is really building the head of a new list and therefore will not wake up the child process. This is because the child process is only invoked after the parent process builds the first node of a new list. 2) The child process catches up to the parent process and tries to read the last node of the list as the parent is filling that node. I think that the best way to give both processes access to the linked list is by using shared memory. I believe that the semaphore implementation in the shared memory utilities provided by System V will prevent the above two cases from occurring. Unfortunately, I can't quite figure out the shared memory utilities. I appreciate any help I can get -- Thanks in advance Steve Hoffman (Hoffman.wbst@Xerox.arpa)
bzs@bu-cs (Barry Shein) (12/18/85)
Try "Advanced UNIX Programming" by Marc J. Rochkind, Prentice-Hall 1985. Shared Memory with an example is covered pp 192-203 (you can probably read it sitting on the floor of the bookstore tho it's certainly worth owning for a person at your stage.) -Barry Shein, Boston University
lrr@princeton.UUCP (Larry Rogers) (12/20/85)
For some ideas on shared memory, messages, and semaphores, I can recommend the ``Advanced Programmer's Guide to UNIX System V'' available from Osborne/ McGraw-Hill. I am one of the authors of the book and I wrote the sections in chapter 7 that describe these things and show examples. As I read your note, I pondered the problem of sharing linked lists between processes as the addresses stored in the data structures comprising the list items cannot have process-specific addresses unless the shared memory is placed at the same virtual location in each process. This is doable when the shared memory is attached, but the processes must communicate this information (common header files?). It's an interesting concept, though. Larry Rogers Princeton University Department of Computer Science Engineering Quadrangle Building, Room C334 Princeton, NJ 08544 UUCP: princeton!lrr CSNET: lrr%princeton@CSnet-relay PHONE: 609 452 6483
zben@umd5.UUCP (12/25/85)
In article <1188@princeton.UUCP> lrr@princeton.UUCP (Larry Rogers) writes: >As I read your note, I pondered the problem of sharing linked lists between >processes as the addresses stored in the data structures comprising the >list items cannot have process-specific addresses unless the shared >memory is placed at the same virtual location in each process. ... This may seem too obvious to mention, but if one keeps pointers RELATIVE to some known location (like the beginning of the data structure in question) then multiple processes can interpret the data structure regardless of its position in the address space... -- "We're taught to cherish what we have | Ben Cranston by what we have no longer..." | zben@umd2.umd.edu ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben