concurrency.md

@@ -71,6 +71,11 @@ expect.
   where most threads are usually blocked.
 - Cooperative systems can be faster, and are simpler to implement
   (see state threads reference).
+- it is fairly difficult to tell the difference between a cooperative (with
+  progress guarentee) and a preemptive system in practice on non contrived
+  programs.
+- STM is trivial and much more efficient to implement. no need to rollback
+  ever except on an explicit exception. Can be almost as fast as IORefs.
 
 **Cons**
 
@@ -104,6 +109,7 @@ expect.
   and possibly deepSeq is disturbing, as is the notion that the
   programmer must think about "what is evaluated" when
   programming concurrent code.
+- The main benefit of preemption, latency, cannot be guarenteed anyway.
 
 **1.b.1.**  Include thread priorities or not?
 
@@ -112,10 +118,12 @@ expect.
 - Some applications require it
 - It affects the fairness/progress guarantees, including the
   possibility of priorities from the outset may be simpler.
+- Need to decide how rigidly to specify them. are they advisory? do we
+  require priority inversion protection?
 
 **Cons**
 
-- Hard to implement, no implementations yet.
+- Can be hard to implement, no implementations yet.
 
 ### 2. Syntax for foreign call annoatations.
 
@@ -246,8 +254,11 @@ incorporate into the main text later.
 
 Additionally, we have a fairness property of `MVar`s:
 
+- every thread is guarenteed to run in a finite amount of time if a program
+  yields infinitly often. (weak fairness)
+
 - A thread blocked on an `MVar` will eventually run, provided there are no other
-  threads holding the `MVar` indefinitely.
+  threads holding the `MVar` indefinitely. (this is implied by the previous rule)
 
 
 This means that `MVar` blocking must be implemented in a fair way, eg. a FIFO of blocked threads.