Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

Comp.os.research: Frequently answered questions [3/3: l/m 13 Aug 1996]
Section - [1.5.4] Address space structure

( Part1 - Part2 - Part3 - Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Forum ]


Top Document: Comp.os.research: Frequently answered questions [3/3: l/m 13 Aug 1996]
Previous Document: [1.5.3] Transfer and caching granularity
Next Document: [1.5.5] Fault tolerance
See reader questions & answers on this topic! - Help others by sharing your knowledge
From: Distributed systems

In a single shared address space system, the system appears as a set
of threads executing in a shared distributed address space.  Objects
always appear at the same addresses on all nodes.  Single address
space systems have had a resurgence in popularity with the arrival of
64-bit processors.  A number of researchers believe that a 64-bit
address space is large enough to act as a single global address space
for all the memory (both primary and secondary) in a distributed
system.  Examples of such systems include Angel, Mungi, and Opal.
Security and protection are a major problem in such systems, and
current approaches either rely on hardware assistance or stochastic
algorithms, or ignore the problem.

Another approach is to divide each process's address space into
different fixed regions, some of which are private and not shared, and
some of which are shared with some other processes.  Ra, the Clouds
kernel, takes this approach using O, P, and K address regions, with
the O region shared between all processes executing in a given object;
the P and K regions are local to a process and kernel, respectively.
Here objects always appear at the same address but may not be visible
from every address space.  By contrast, some systems, including Mirage
and Mach, allow shared data to exist at differing addresses in
different processes address spaces.  However, neither system does
transparent pointer translation, so the address changes are not
entirely transparent to the application.

As for the structuring of the shared region itself, some systems --
for example, IVY and Mether -- use a single flat region: one
continuous range of virtual addresses represent the shared address
space and are managed by the DSM system.  This single address space is
usually sub-divided into pages.  Most systems use paged segmentation:
the shared region consists of disjoint pieces, which are usually
managed separately and are not all mapped in any one process.
Frequently, the segments (sometimes called memory objects, or windows)
are related to the backing store.  For example, in Clouds, the object
address space consists of windows onto larger segments; these segments
are usually maintained on secondary storage.

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA




Top Document: Comp.os.research: Frequently answered questions [3/3: l/m 13 Aug 1996]
Previous Document: [1.5.3] Transfer and caching granularity
Next Document: [1.5.5] Fault tolerance

Part1 - Part2 - Part3 - Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
os-faq@cse.ucsc.edu





Last Update March 27 2014 @ 02:12 PM