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.1.3] Application-specific coherence

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


Top Document: Comp.os.research: Frequently answered questions [3/3: l/m 13 Aug 1996]
Previous Document: [1.5.1.2] Relaxing consistency
Next Document: [1.5.2] Access synchronisation
See reader questions & answers on this topic! - Help others by sharing your knowledge
From: Distributed systems

From [Cheriton, 86]:
  `Problem-oriented shared memory' is a shared memory that implements
  fetch and store operations specialised to the particular problem or
  application it is supporting.  In particular, a problem-oriented
  shared memory commonly provides a specialised form of consistency
  and consistency maintenance that exploits application-specific
  semantics.
Cheriton goes on to propose that consistency constraints be relaxed
and more use be made of problem semantics.  He suggests that, in some
cases, stale data may be detected on use by the client, and the client
may then recover.  A example would be hint caching.  In some
applications, stale data may actually be sufficiently accurate,
provided that the client can obtain up to date information when
necessary.  In other applications, some data may be optional in the
sense that the client can continue without it.  Other applications may
tolerate having the results of store operations being lost or undone,
for example, an application that regularly updates the entire data
set.

Another approach is presented by the designers of Munin, where the
runtime system accepts hints from the compiler or user to determine
the coherence mechanism to be used for each object.  The default, in
the absence of hints, is to use a general read-write consistency
mechanism, much like that employed by IVY.  Munin supports several
different object types that are based on the results of a survey of
shared memory access characteristics.  The results of the survey
showed that a very small percentage of all accesses to shared data
fall under the general read-write type.  The Munin designers also note
that a program moves through various stages of execution, and the
types associated with objects change as time progresses

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.1.2] Relaxing consistency
Next Document: [1.5.2] Access synchronisation

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