[comp.sys.next] shared memory on NeXT

george@tut.cis.ohio-state.edu (George M. Jones) (10/19/88)

If my understanding is correct you can put up to 4 processor boards
into the machine, each containing a processor and 4 meg of memory.
Does anyone have a clear idea if and how processors will access memory
on other boards ?

Related question: will there be any sort of process migration, i.e.
you get blocked for i/o while running on CPU A and get restarted on
CPU B.

Ideas from those in-the-know ?

---George Jones

-- 
OSU Computer & Inf. Science 2036 Neil Ave.,Columbus,Ohio 43210. 614-292-7325
george@cis.ohio-state.edu or ...!osu-cis!george
What's the opposite of progress ?  Congress.

cmaeda@a.gp.cs.cmu.edu (Christopher Maeda) (03/01/91)

Why not just rewrite your code to use ports and messages?  A mach
message (within a single host) is implemented as a piece of shared
memory anyway.  You don't need to mess with semaphores since the OS
does the synchronization for you when it delivers the message.  You
also get network transparency for free.

I imagine the reason the vm code doesn't let arbitrary processes share
pieces of memory is that you are supposed to use ports and messages
for this sort of thing.



-- 
Chris Maeda, CMU CS                     |Mail:	cmaeda@cs.cmu.edu
Yow!  I find I enjoy netnews more after |UUCP:  fuck if I know
having a couple of twinkies and a coke. |(si:halt "boot
Am I a Unix Weenie yet?                 |")

songer@orchestra.ecn.purdue.edu (Christopher M Songer) (03/01/91)

Christopher Maeda writes:
>Why not just rewrite your code to use ports and messages?  A mach
>message (within a single host) is implemented as a piece of shared
>memory anyway.  You don't need to mess with semaphores since the OS
>does the synchronization for you when it delivers the message.  You
>also get network transparency for free.
>
>I imagine the reason the vm code doesn't let arbitrary processes share
>pieces of memory is that you are supposed to use ports and messages
>for this sort of thing.

Well,
    
     I guess my first answer is laziness. When a program really uses
the shared memory, it tends to permeate the program. It is not something
which is localized to a few spots. Sure there are only a couple of shm*
calls, but the pointers that get returned can be used all over.  So a 
program which REALLY uses shared memory is a pain to port. I'd like to 
do it once and for all, all up front. I want to make a library and
a set headers that I can use to make sysV programs run with NO extra
work.

     The CMU version of mach has a way to do shared memory cleanly.
What you do is get a memory object and register yourself as the pager
for that object. All of the programs sharing the memory use the
vm_map command to map that memory object into their address space
and then as the pager, you get called to handle any page faults. This
scheme could be hidden behind the shm* calls. (All this is from
a couple of tech documents at the CMU ftp server wb1.cs.cmu.edu)
So while you are right, arbitrary processes are not supposed to
shared memory directly, there is still a clean way to implement it.

-Chris