Index: doc/papers/concurrency/Paper.tex
===================================================================
--- doc/papers/concurrency/Paper.tex	(revision adb602421edaad94c142d125c8c4fdecd8f9835b)
+++ doc/papers/concurrency/Paper.tex	(revision 2ebcb28d39c5081a5b63a5e1289832b9401dd1e9)
@@ -1309,6 +1309,6 @@
 void print( Tree & mutex tree ) {			$\C{// prefix traversal}$
 	// write value
-	print( tree->left );					$\C{// multiply acquire monitor lock for tree on each recursion}$
-	print( tree->right );
+	print( *tree->left );					$\C{// multiply acquire monitor lock for tree on each recursion}$
+	print( *tree->right );
 }
 \end{cfa}
@@ -2089,5 +2089,5 @@
 In \CFA, ordering of monitor acquisition relies on memory ordering to prevent deadlock~\cite{Havender68}, because all objects have distinct non-overlapping memory layouts, and mutual-exclusion for a monitor is only defined for its lifetime.
 When a mutex call is made, pointers to the concerned monitors are aggregated into a variable-length array and sorted.
-This array persists for the entire duration of the mutual-exclusion and is used extensively for synchronization operations.
+This array persists for the entire duration of the mutual exclusion and is used extensively for synchronization operations.
 
 To improve performance and simplicity, context switching occurs inside a routine call, so only callee-saved registers are copied onto the stack and then the stack register is switched;
@@ -2170,5 +2170,6 @@
 \end{cfa}
 The method used to get time is @clock_gettime( CLOCK_REALTIME )@.
-Each benchmark is performed @N@ times, where @N@ varies depending on the benchmark, the total time is divided by @N@ to obtain the average time for a benchmark.
+Each benchmark is performed @N@ times, where @N@ varies depending on the benchmark;
+the total time is divided by @N@ to obtain the average time for a benchmark.
 All omitted tests for other languages are functionally identical to the shown \CFA test.
 
@@ -2315,9 +2316,9 @@
 }
 \end{cfa}
-\captionof{figure}{\CFA Internal scheduling benchmark}
+\captionof{figure}{\CFA Internal-scheduling benchmark}
 \label{f:int-sched}
 
 \centering
-\captionof{table}{Internal scheduling comparison (nanoseconds)}
+\captionof{table}{Internal-scheduling comparison (nanoseconds)}
 \label{tab:int-sched}
 \bigskip
@@ -2366,10 +2367,10 @@
 }
 \end{cfa}
-\captionof{figure}{\CFA external scheduling benchmark}
+\captionof{figure}{\CFA external-scheduling benchmark}
 \label{f:ext-sched}
 
 \centering
 
-\captionof{table}{External scheduling comparison (nanoseconds)}
+\captionof{table}{External-scheduling comparison (nanoseconds)}
 \label{tab:ext-sched}
 \bigskip
@@ -2397,5 +2398,5 @@
 }
 \end{cfa}
-\captionof{figure}{\CFA object creation benchmark}
+\captionof{figure}{\CFA object-creation benchmark}
 \label{f:creation}
 
Index: doc/papers/concurrency/notes/cor-thread-traits.c
===================================================================
--- doc/papers/concurrency/notes/cor-thread-traits.c	(revision adb602421edaad94c142d125c8c4fdecd8f9835b)
+++ 	(revision )
@@ -1,90 +1,0 @@
-//-----------------------------------------------------------------------------
-// Coroutine trait
-// Anything that implements this trait can be resumed.
-// Anything that is resumed is a coroutine.
-trait is_coroutine(dtype T) {
-      void main(T* this);
-      coroutine_handle* get_handle(T* this);
-}
-
-//-----------------------------------------------------------------------------
-forall(dtype T | {coroutine_handle* T.c})
-coroutine_handle* get_handle(T* this) {
-	return this->c
-}
-
-//-----------------------------------------------------------------------------
-struct myCoroutine {
-	int bla;
-	coroutine_handle c;
-};
-
-void main(myCoroutine* this) {
-	sout | this->bla | endl;
-}
-
-void foo() {
-	//Run the coroutine
-	myCoroutine myc;
-	resume(myc);
-}
-
-//-----------------------------------------------------------------------------
-// Thread trait
-// Alternative 1
-trait is_thread(dtype T) { 
-      void main(T* this);
-      thread_handle* get_handle(T* this);
-	thread T;
-};
-
-//-----------------------------------------------------------------------------
-forall(dtype T | {thread_handle* T.t})
-thread_handle* get_handle(T* this) {
-	return this->t
-}
-
-//-----------------------------------------------------------------------------
-thread myThread {
-	int bla;
-	thread_handle c;
-};
-
-void main(myThread* this) {
-	sout | this->bla | endl;
-}
-
-void foo() {
-	//Run the thread
-	myThread myc;
-}
-
-//-----------------------------------------------------------------------------
-// Thread trait
-// Alternative 2
-trait is_thread(dtype T) {
-      void main(T* this);
-      thread_handle* get_handle(T* this);
-	
-};
-
-//-----------------------------------------------------------------------------
-forall(dtype T | {thread_handle* T.t})
-thread_handle* get_handle(T* this) {
-	return this->t
-}
-
-//-----------------------------------------------------------------------------
-struct myThread {
-	int bla;
-	thread_handle c;
-};
-
-void main(myThread* this) {
-	sout | this->bla | endl;
-}
-
-void foo() {
-	//Run the thread
-	thread(myThread) myc;
-}
Index: doc/papers/concurrency/notes/lit-review.md
===================================================================
--- doc/papers/concurrency/notes/lit-review.md	(revision adb602421edaad94c142d125c8c4fdecd8f9835b)
+++ 	(revision )
@@ -1,25 +1,0 @@
-lit review :
-
-Lister77 : nested monitor calls
-	- explains the problem
-	- no solution
-	- Lister : An implementation of monitors.
-	- Lister : Hierarchical monitors.
-
-Haddon77 : Nested monitor calls
-	- monitors should be release before acquiring a new one.
-
-Horst Wettstein : The problem of nested monitor calls revisited
-	- Solves nested monitor by allowing barging
-
-David L. Parnas : The non problem of nesied monitor calls
-	- not an actual problem in real life
-
-M. Joseph and VoR. Prasad : More on nested monitor call
-	- WTF... don't use monitors, use pure classes instead, whatever that is
-
-Joseph et al, 1978). 
-
-Toby bloom : Evaluating Synchronization Mechanisms
-	- Methods to evaluate concurrency
-
Index: doc/papers/concurrency/notes/notes.md
===================================================================
--- doc/papers/concurrency/notes/notes.md	(revision adb602421edaad94c142d125c8c4fdecd8f9835b)
+++ 	(revision )
@@ -1,14 +1,0 @@
-Internal scheduling notes.
-
-Internal scheduling requires a stack or queue to make sense.
-We also need a stack of "monitor contexts" to be able to restuore stuff.
-
-Multi scheduling try 1 
- - adding threads to many monitors and synching the monitors
- - Too hard
-
-Multi scheduling try 2
- - using a leader when in a group
- - it's hard but doable to manage who is the leader and keep the current context
- - basically __monitor_guard_t always saves an restore the leader and current context
-