Tech Insider					     Technology and Trends


			      USENET Archives

Path: sparky!uunet!spool.mu.edu!howland.reston.ans.net!usenet.ins.cwru.edu!
po.CWRU.Edu!sdh
From: s...@po.CWRU.Edu (Scott D. Heavner)
Newsgroups: comp.os.linux
Subject: Getting two programs to share variables in memory:
Date: 15 Mar 1993 03:57:07 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Lines: 156
Message-ID: <1o0uqjINN3i5@usenet.INS.CWRU.Edu>
Reply-To: s...@po.CWRU.Edu (Scott D. Heavner)
NNTP-Posting-Host: thor.ins.cwru.edu


        I am currently adapting some code which we were running on
a Sun and a VME cage.  I want to be able to run simulations at home
using the same code which allows all the processors on the cage
access to some reserved memory in the cage.

        Now for the re-phrasing:  I have about 6 programs (not
subroutines) which I want to have running at once and which
can all communicate via some reserved memeory space.  I want to
keep them as separate programs so that I can kill and restart
individual programs as well as retain the same code as I am using on
the cage.

        We have a big structure (gmem) which contains up to 2M of
variables.  Every program includes gmem_defs.h to make sure the
stucture order/size is uniform.  When it comes time to initialize
the gmem pointer, there is a map function which returns the
current address of gmem [map(address,size) -- address = 0x8000000 or
some number being the address of the memory card in the VME backplane,
size = sizeof(struct global_mem_struc)].  The map function just
checks the address and puts it at the start of the page nearest the
one you requested (as well as taking care of all the bus inteface
garbage).

        This was my idea (which didn't work): On the first call to
map, I do a malloc and save the address to a file.  On subsequent
calls, I read the address from the file and assign that to the
map function.  However, it appears that I don't get an absolute
address back (probably something to do with paging, what do I know --
DOS + an XT made life a whole lot simpler :)  Anyhow, it always
saves the same address 0x8000, even if I rerun the main program with
the old one still going.

	What follows are some watered down test programs for anyone 
who thinks they can help (I'm not claiming responsablilty if 
it trashes your system -- It hasn't hurt mine yet).  All that One
should have to do is make the programs "main" and "main2" and run
them on separate ttys (or put a line into main.c like 
	system("/doshell /dev/tty4 ./main2");
or
	system("xterm -e ./main2");


	One other question: Is this something I should be trying?

				Scott
				s...@po.cwru.edu

Code

-- 
HELP! I'm being held prisoner in a .sig file factory.

Newsgroups: comp.os.linux
Path: sparky!uunet!mcsun!sun4nl!dutrun!donau!donau.et.tudelft.nl!bas
From: b...@phys.uva.nl (Bas de Bakker)
Subject: Re: Getting two programs to share variables in memory:
In-Reply-To: sdh@po.CWRU.Edu's message of 15 Mar 1993 03: 57:07 GMT
Message-ID: <BAS.93Mar15105635@carlo.phys.uva.nl>
Sender: n...@donau.et.tudelft.nl (UseNet News System)
Nntp-Posting-Host: carlo.phys.uva.nl
Organization: Institute for Theoretical Physics, Amsterdam, the Netherlands
References: <1o0uqjINN3i5@usenet.INS.CWRU.Edu>
Date: Mon, 15 Mar 1993 15:56:35 GMT
Lines: 28

>>>>> On 15 Mar 1993 03:57:07 GMT, s...@po.CWRU.Edu (Scott D. Heavner) said:

sdh>         This was my idea (which didn't work): On the first call to
sdh> map, I do a malloc and save the address to a file.  On subsequent
sdh> calls, I read the address from the file and assign that to the
sdh> map function.  However, it appears that I don't get an absolute
sdh> address back (probably something to do with paging, what do I know --
sdh> DOS + an XT made life a whole lot simpler :)  Anyhow, it always
sdh> saves the same address 0x8000, even if I rerun the main program with
sdh> the old one still going.

Programs under linux don't share the same physical memory, even when
using the same addresses. If you want to know how this is done, read a
386 reference and the kernel sources.

Many un*x versions have a number of system calls to use shared memory.
These are not in the standard linux kernel, but you could take a look
at the IPC patches available (haven't used any of them myself).

Another way of sharing memory between processes is by mapping the
/dev/zero special file in memory. I just read that linux .99.7
supports this feature.

So, if noone takes the time to explain this stuff in detail on this
group (I won't, too lazy) get some appropriate unix manuals and look
for mmap() and anything that matches shm*().

Bas.

Newsgroups: comp.os.linux
Path: sparky!uunet!news.tele.fi!news.funet.fi!hydra!klaava!torvalds
From: torva...@klaava.Helsinki.FI (Linus Torvalds)
Subject: Re: Getting two programs to share variables in memory:
Message-ID: <1993Mar15.184328.23265@klaava.Helsinki.FI>
Organization: University of Helsinki
References: <1o0uqjINN3i5@usenet.INS.CWRU.Edu> 
<BAS.93Mar15105635@carlo.phys.uva.nl>
Date: Mon, 15 Mar 1993 18:43:28 GMT
Lines: 21

In article <BAS.93Mar15105...@carlo.phys.uva.nl> b...@phys.uva.nl 
(Bas de Bakker) writes:
>
>Another way of sharing memory between processes is by mapping the
>/dev/zero special file in memory. I just read that linux .99.7
>supports this feature.

Actually, 0.99.7 supports only a limited mmap() on /dev/zero: only
MAP_PRIVATE is supported.  mmap'ing /dev/zero with MAP_SHARED would take
some additional work - definitely not trivial (it includes maintaing
lists of pages used for the mapping etc).  So the /dev/zero mmap feature
is currently only useful for zeroing out big areas (and unmapping
underlying areas: useful mostly for malloc() type things, sparse arrays
etc). 

The only way currently to get shared memory is to use the IPC patches,
which won't work with pl7 in their current version.  Pl7 cleaned up the
memory manager quite a bit, so hopefully future versions of the IPC
patches will be cleaner (and eventually easier to incorporate into the
standard kernel). 

		Linus

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO v IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/