[ Usenet FAQs | Web FAQs | Documents | RFC Index ]
    Search the FAQ Archives

Part1 - Part2 - Part3 - Single Page

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


[1.5.1.3] Application-specific coherence


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



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 October 22 2009 @ 05:32 AM

Some parts © 2009 Advameg, Inc.