| 139 |
|
freeze the collection while iterating, so it may (or may not) reflect |
| 140 |
|
any updates since the iterator was created. |
| 141 |
|
|
| 142 |
+ |
<a name="MemoryVisibility"> |
| 143 |
|
<h2> Memory Consistency Properties </h2> |
| 144 |
|
|
| 145 |
|
<a href="http://java.sun.com/docs/books/jls/third_edition/html/memory.html"> |
| 153 |
|
<i>happens-before</i> relationships. In particular: |
| 154 |
|
|
| 155 |
|
<ul> |
| 156 |
< |
<li>Each action in a thread happens before every action in that |
| 156 |
> |
<li>Each action in a thread <i>happens-before</i> every action in that |
| 157 |
|
thread that comes later in the program's order. |
| 158 |
|
|
| 159 |
|
<li>An unlock (<tt>synchronized</tt> block or method exit) of a |
| 160 |
< |
monitor happens before every subsequent lock (<tt>synchronized</tt> |
| 160 |
> |
monitor <i>happens-before</i> every subsequent lock (<tt>synchronized</tt> |
| 161 |
|
block or method entry) of that same monitor. And because |
| 162 |
|
the <i>happens-before</i> relation is transitive, all actions |
| 163 |
|
of a thread prior to unlocking happen before all actions |
| 164 |
|
subsequent to any thread locking that monitor. |
| 165 |
|
|
| 166 |
< |
<li>A write to a <tt>volatile</tt> field happens before every |
| 166 |
> |
<li>A write to a <tt>volatile</tt> field <i>happens-before</i> every |
| 167 |
|
subsequent read of that same field. Writes and reads of |
| 168 |
|
<tt>volatile</tt> fields have similar memory consistency effects |
| 169 |
|
as entering and exiting monitors, but do <em>not</em> entail |
| 170 |
|
mutual exclusion locking. |
| 171 |
|
|
| 172 |
< |
<li>A call to <tt>start</tt> on a thread happens before any action in the |
| 172 |
> |
<li>A call to <tt>start</tt> on a thread <i>happens-before</i> any action in the |
| 173 |
|
started thread. |
| 174 |
|
|
| 175 |
< |
<li>All actions in a thread happen before any other thread |
| 175 |
> |
<li>All actions in a thread <i>happen-before</i> any other thread |
| 176 |
|
successfully returns from a <tt>join</tt> on that thread. |
| 177 |
|
|
| 178 |
|
</ul> |
| 189 |
|
removed from that collection. |
| 190 |
|
|
| 191 |
|
<li>State changes to a <tt>Runnable</tt> object made prior to |
| 192 |
< |
submission to an <tt>Executor</tt> happen before its execution. And |
| 192 |
> |
submission to an <tt>Executor</tt> <i>happen-before</i> its execution. And |
| 193 |
|
similarly for a <tt>Callable</tt> object submitted to an |
| 194 |
|
<tt>ExecutorService</tt>. |
| 195 |
|
|
| 196 |
|
<li>State changes to a <tt>Future</tt> made prior to it becoming |
| 197 |
< |
available happen before access via <tt>Future.get()</tt>. |
| 197 |
> |
available <i>happen-before</i> access via <tt>Future.get()</tt>. |
| 198 |
|
|
| 199 |
|
<li>Actions prior to "releasing" synchronizer methods such as |
| 200 |
|
<tt>Lock.unlock</tt>, <tt>Semaphore.release</tt>, |
| 201 |
|
<tt>CountDownLatch.countDown</tt> and <tt>Condition.signal</tt> |
| 202 |
< |
happen before actions subsequent to "acquiring" methods such as |
| 202 |
> |
<i>happen-before</i> actions subsequent to a successful "acquiring" method such as |
| 203 |
|
<tt>Lock.lock</tt>, <tt>Semaphore.acquire</tt>, and |
| 204 |
|
<tt>CountDownLatch.await</tt> on the same synchronizer object. |
| 205 |
|
|
| 206 |
< |
<li>Actions prior to symmetric synchronizer methods such as |
| 207 |
< |
<tt>CyclicBarrier.await</tt> and <tt>Exchanger.exchange</tt> happen |
| 208 |
< |
before those subsequent to the matching actions in other threads. |
| 206 |
> |
<li>Actions prior to calling <tt>Exchanger.exchange</tt> |
| 207 |
> |
<i>happen-before</i> those subsequent to the matching actions in |
| 208 |
> |
other threads. |
| 209 |
> |
|
| 210 |
> |
<li>Actions prior to calling <tt>CyclicBarrier.await</tt> |
| 211 |
> |
<i>happen-before</i> actions performed by the barrier action, and |
| 212 |
> |
actions performed by the barrier action <i>happen-before</i> actions |
| 213 |
> |
subsequent to the return from <tt>await</tt> in other threads. |
| 214 |
|
|
| 215 |
|
</ul> |
| 216 |
|
|
