Path: utzoo!attcan!uunet!husc6!rutgers!iuvax!pur-ee!hankd
From: hankd@pur-ee.UUCP (Hank Dietz)
Newsgroups: comp.arch
Subject: Re: Today's dumb question...
Summary: Shared memory isn't a software issue to be solved
Message-ID: <8104@pur-ee.UUCP>
Date: 11 May 88 17:06:47 GMT
References: <503@xios.XIOS.UUCP> <2676@pdn.UUCP> <674@cernvax.UUCP>
Organization: Purdue University Engineering Computer Network
Lines: 32

In article <674@cernvax.UUCP>, hjm@cernvax.UUCP (hjm) writes:
> 	- shared-memory is not necessary; it's a software issue that shouldn't
> 	  be solved in hardware.

Shared memory's full name is "shared memory address space" -- it means
simply that some portion of the memory is addressible by more than one
processor.  In other words, it says that although memory may be physically
distributed, and may have access times which depend on the physical
structure as well as on bus/network traffic conditions, the WAY in which it
is referenced appears as a conventional load/store on an address.

The alternative is to create a MESSAGE which REQUESTS THAT SOMETHING ELSE
REFERENCE the desired memory location.  How do you create a message?  Well,
maybe a GET/PUT instruction or somesuch, but the key idea is that you're
sending the message TO SOME ACTIVE ELEMENT, not to a memory address.

As for which is better, because most message-passing systems only use
messages to access non-local memory, one must distinguish between local and
non-local references at compile-time to generate efficient code --
unfortunately, this is not always possible, and since the shared-memory
model doesn't require this distinction be made at compile time, it is in
some sense more powerful.  The implementation difficulty usually depends on
how you connect to memory:  for word transfers, shared-memory is easier; for
longer block transfers, messages are easier...  for the obvious reasons.

Shared memory DOES NOT MEAN CONSTANT ACCESS TIME independent of memory cell
addressed -- if that's your "software" definition of shared-memory, forget
it, because no highly-parallel machine will *ever* support that.  Ok, maybe
your software would still run if you wrote it with that assumption, but it
ain't gonna run fast, and that is what parallel processing is all about.

						-hankd