4 A PRIMER ON MEMORY CONSISTENCY AND CACHE COHERENCE
ask for it with a FENCE instruction (e.g., a FENCE after the last data update but before the flag
write). The chapter then extends the formalism of the previous two chapters to handle XC and
discusses how to implement XC (with considerable reordering between the cores and the coher-
ence protocol). The chapter then discusses a way in which many programmers can avoid thinking
about relaxed models directly: if they add enough FENCEs to ensure their program is data-race
free (DRF), then most relaxed models will appear SC. With “SC for DRF,” programmers can get
both the (relatively) simple correctness model of SC with the (relatively) higher performance of
XC. For those who want to reason more deeply, the chapter concludes by distinguishing acquires
from releases, discussing write atomicity and causality, pointing to commercial examples (including
an IBM Power case study), and touching upon high-level language models ( Java and C++).
Returning to the real-world consistency example of the class schedule, we can observe that
the combination of an email system, a human web administrator, and a text-messaging system rep-
resents an extremely weak consistency model. To prevent the problem of a diligent student going to
the wrong room, the university registrar needed to perform a FENCE operation after her email to
ensure that the online schedule was updated before sending the text message.
1.2 COHERENCE (A.K.A., CACHE COHERENCE)
Unless care is taken, a coherence problem can arise if multiple actors (e.g., multiple cores) have access
to multiple copies of a datum (e.g., in multiple caches) and at least one access is a write. Consider
an example that is similar to the memory consistency example. A student checks the online sched-
ule of courses, observes that the Computer Architecture course is being held in Room 152 (reads
the datum), and copies this information into her notebook (caches the datum). Subsequently, the
university registrar decides to move the class to Room 252 and updates the online schedule (writes
to the datum). The student’s copy of the datum is now stale, and we have an incoherent situation.
If she goes to Room 152, she will fail to find her class. Examples of incoherence from the world
of computing, but not including computer architecture, include stale web caches and programmers
using un-updated code repositories.
Access to stale data (incoherence) is prevented using a coherence protocol, which is a set of
rules implemented by the distributed set of actors within a system. Coherence protocols come in
many variants but follow a few themes, as developed in Chapters 6–9.
Chapter 6 presents the big picture of cache coherence protocols and sets the stage for the
subsequent chapters on specific coherence protocols. This chapter covers issues shared by most co-
herence protocols, including the distributed operations of cache controllers and memory controllers
and the common MOESI coherence states: modified (M), owned (O), exclusive (E), shared (S), and
invalid (I). Importantly, this chapter also presents our table-driven methodology for presenting pro-
tocols with both stable (e.g., MOESI) and transient coherence states. Transient states are required
我的内容管理
展开
