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.2] Relaxing consistency

( Part1 - Part2 - Part3 - Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Business Photos and Profiles ]


Top Document: Comp.os.research: Frequently answered questions [3/3: l/m 13 Aug 1996]
Previous Document: [1.5.1.1] Strictly consistent systems
Next Document: [1.5.1.3] Application-specific coherence
See reader questions & answers on this topic! - Help others by sharing your knowledge
From: Distributed systems

Permitting temporary inconsistencies is a common method of increasing
performance in distributed systems.  Memory is said to be loosely
coherent if the value returned by a read operation is the value
written by an update operation to the same object that `could' have
immediately preceded the read operation in some legal schedule of the
threads in execution [Bennett et al., 90].

Using loose coherence, more than one thread may have write access to
the same object, provided that the programmer knows that the writes
will not conflict.

Another memory consistency model is `release consistency'
[Gharachorloo et al., 90], in which memory accesses are divided into
ordinary and synchronisation-related accesses.  The latter are further
divided into `acquire' and `release' operations.  The `acquire'
operation indicates that shared data is needed, and a processor's
updates are not guaranteed to be performed at other nodes until a
`release' is performed.  The primary advantage of this form of
consistency is that it allows consistency updates to be tied to
synchronisation events, and therefore to be delayed until actually
needed by applications.  However, most release consistent systems
require the programmer to make explicit use of `acquire' and `release'
operations.

A DSM system called Midway introduces another new consistency model,
`entry consistency' [Bershad et al., 93].  Entry consistency is weaker
than many of the other models suggested, including release
consistency; it requires explicit annotations to associate
synchronisation objects and data.  On an `acquire', only the data
associated with the synchronisation object is guaranteed to be
consistent.  This extra weakness permits higher performance
implementations of the underlying consistency protocols to be written.
Midway also supports stronger consistency models, so that the
application programmer can trade-off performance against the extra
effort required to write entry consistent programs.

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.1] Strictly consistent systems
Next Document: [1.5.1.3] Application-specific coherence

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