From 9c2776a5cbf6a68387bd4921078ab96762f54b3a Mon Sep 17 00:00:00 2001 From: Ben Pfaff Date: Tue, 26 Sep 2006 14:59:41 +0000 Subject: [PATCH] Change "Memory Barriers" to "Optimization Barriers". Thanks to Joshua Haberman for pointing out the issue. --- doc/reference.texi | 20 ++++++++++---------- doc/threads.texi | 4 ++-- src/threads/synch.h | 6 +++--- ta-advice/HW1 | 4 ++-- 4 files changed, 17 insertions(+), 17 deletions(-) diff --git a/doc/reference.texi b/doc/reference.texi index 9b02d5a..2bfbac9 100644 --- a/doc/reference.texi +++ b/doc/reference.texi @@ -552,7 +552,7 @@ synchronization primitives to help out. * Semaphores:: * Locks:: * Monitors:: -* Memory Barriers:: +* Optimization Barriers:: @end menu @node Disabling Interrupts @@ -844,8 +844,8 @@ char get (void) @{ @} @end example -@node Memory Barriers -@subsection Memory Barriers +@node Optimization Barriers +@subsection Optimization Barriers @c We should try to come up with a better example. @c Perhaps something with a linked list? @@ -912,11 +912,11 @@ and restricts its latitude for optimization. However, the semantics of @samp{volatile} are not well-defined, so it is not a good general solution. -Usually, the best solution is to use a compiler feature called a -@dfn{memory barrier}, a special statement that prevents the compiler -from reordering memory operations across the barrier. In Pintos, -@file{threads/synch.h} defines the @code{barrier()} macro as a memory -barrier. Here's how we would use a memory barrier to fix this code: +Usually, the best solution is to use a compiler feature called an +@dfn{optimization barrier}, a special statement that prevents the compiler +from reordering operations across the barrier. In Pintos, +@file{threads/synch.h} defines the @code{barrier()} macro as an optimization +barrier. Here's how we would use a optimization barrier to fix this code: @example timer_put_char = 'x'; @@ -925,7 +925,7 @@ timer_do_put = true; @end example The compiler also treats invocation of any function defined externally, -that is, in another source file, as a limited form of a memory barrier. +that is, in another source file, as a limited form of a optimization barrier. Specifically, the compiler assumes that any externally defined function may access any statically or dynamically allocated data and any local variable whose address is taken. This often means that explicit @@ -933,7 +933,7 @@ barriers can be omitted, and, indeed, this is why the base Pintos code does not need any barriers. A function defined in the same source file, or in a header included by -the source file, cannot be relied upon as a memory barrier. +the source file, cannot be relied upon as a optimization barrier. This applies even to invocation of a function before its definition, because the compiler may read and parse the entire source file before performing optimization. diff --git a/doc/threads.texi b/doc/threads.texi index cbcda16..ac28ba8 100644 --- a/doc/threads.texi +++ b/doc/threads.texi @@ -40,7 +40,7 @@ The first step is to read and understand the code for the initial thread system. Pintos already implements thread creation and thread completion, a simple scheduler to switch between threads, and synchronization -primitives (semaphores, locks, condition variables, and memory +primitives (semaphores, locks, condition variables, and optimization barriers). Some of this code might seem slightly mysterious. If @@ -170,7 +170,7 @@ Infrastructure}, for more information. @item synch.c @itemx synch.h Basic synchronization primitives: semaphores, locks, condition -variables, and memory barriers. You will need to use these for +variables, and optimization barriers. You will need to use these for synchronization in all four projects. @xref{Synchronization}, for more information. diff --git a/src/threads/synch.h b/src/threads/synch.h index 53a5ee4..6b8f550 100644 --- a/src/threads/synch.h +++ b/src/threads/synch.h @@ -41,10 +41,10 @@ void cond_wait (struct condition *, struct lock *); void cond_signal (struct condition *, struct lock *); void cond_broadcast (struct condition *, struct lock *); -/* Memory barrier. +/* Optimization barrier. - The compiler will not reorder operations that access memory - across a memory barrier. */ + The compiler will not reorder operations across an + optimization barrier. */ #define barrier() asm volatile ("") #endif /* threads/synch.h */ diff --git a/ta-advice/HW1 b/ta-advice/HW1 index 99b59e1..1783dd0 100644 --- a/ta-advice/HW1 +++ b/ta-advice/HW1 @@ -36,8 +36,8 @@ at the appropriate time. Details that distinguish solutions include: - Synchronization: Most solutions manipulate the list with interrupts disabled to protect against the interrupt handler. Other solutions are possible but most of them are - incorrect--watch out for missing memory barriers (see the - Memory Barriers section in the reference guide) or bad + incorrect--watch out for missing optimization barriers (see the + Optimization Barriers section in the reference guide) or bad assumptions of atomicity when there is none. In most solutions only the list insertion (typically a -- 2.30.2