doc update

README.md

@@ -12,7 +12,10 @@ $ java -jar target/jcstress.jar -v -t HappensBeforeExample
 ```
 * reports in readable form: `results/jcstress.HappensBeforeExample`
 
-# happens-before
+## happens-before
+* in computer science, the happened-before relation is a relation between the result of two events, 
+such that if one event should happen before another event, the result must reflect that, even if those 
+events are in reality executed out of order (usually to optimize program flow)
 * compilers may generate instructions in a different order than in the source code
 * variables could be stored in registers instead of memory
 * processors may execute instructions in parallel or out of order
@@ -48,35 +51,23 @@ $ java -jar target/jcstress.jar -v -t HappensBeforeExample
     * **finalizer rule**: the end of a constructor for an object happens-before
     the start of the finalizer for that object
     * **transitivity**: A happens-before B AND B happens-before C => A happens-before C
-    * When two
-      threads synchronize on different locks, we can’t say anything about the ordering
-      of actions between them—there is no happens-before relation between the actions
-      in the two threads
+    * when two threads synchronize on different locks, we can’t say anything about the ordering
+      of actions between them — there is no happens-before relation
 
-# volatile
-A field may be declared **volatile**, in which case the Java Memory Model ensures that all threads see 
-a consistent value for the variable. More precisely that means, that every read of a volatile variable 
-will be read from the computer's main memory, and not from the CPU cache, and that every write to a 
-volatile variable will be written to main memory, and not just to the CPU cache.
-
-It prevents compiler / CPU code reordering.
-
-**Happens-before** - In computer science, the happened-before relation is a relation between the result 
-of two events, such that if one event should happen before another event, the result must reflect that, 
-even if those events are in reality executed out of order (usually to optimize program flow).
-
-When we write to a volatile variable, it creates a **happens-before** relationship with each subsequent 
-read of that same variable. So any memory writes that have been done until that volatile variable write, 
-will subsequently be visible to any statements that follow the read of that volatile variable.
-
-Characterizing the situations under which volatile can be used safely involves determining whether 
+## volatile
+* Java Memory Model ensures that all threads see a consistent value for the variable
+* every read of a volatile variable will be read from the computer's main memory, and not from the CPU cache
+* every write to a volatile variable will be written to main memory, and not just to the CPU cache
+* prevents compiler / CPU code reordering
+* when we write to a volatile variable, it creates a **happens-before** relationship with each subsequent 
+read of that same variable 
+    * so any memory writes that have been done until that volatile variable write, will subsequently 
+    be visible to any statements that follow the read of that volatile variable
+* characterizing the situations under which volatile can be used safely involves determining whether 
 each update operation can be performed as a single atomic update.
 
-_Remark_:
+### remarks
 * updates to non-volatile long or a double may not be atomic, and
 * Java operators like ++ and += are not atomic.
-
-1. Why an Object member variable can't be both final and volatile in Java?
-    Essentially, when you declare object field as final you need to initialize it in object's 
-    constructor and then final field won't change it's value. And JMM promises that after ctor is 
-    finished any thread will see the same (correct) value of final field.
+* why an Object member variable can't be both final and volatile in Java?
+    * JMM promises that after `ctor` is finished any thread will see the same (correct) value of final field