Index: doc/LaTeXmacros/lstlang.sty
===================================================================
--- doc/LaTeXmacros/lstlang.sty	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ doc/LaTeXmacros/lstlang.sty	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
@@ -107,13 +107,10 @@
 \lstdefinelanguage{CFA}[ANSI]{C}{
 	morekeywords={
-		_Alignas, _Alignof, __alignof, __alignof__, asm, __asm, __asm__, _At, __attribute,
+		_Alignas, _Alignof, __alignof, __alignof__, asm, __asm, __asm__, _At, _Atomic, __attribute,
 		__attribute__, auto, _Bool, catch, catchResume, choose, _Complex, __complex, __complex__,
-		__const, __const__, disable, dtype, enable, __extension__, fallthrough, fallthru,
-		finally, forall, ftype, _Generic, _Imaginary, inline, __label__, lvalue, _Noreturn, one_t, 
-		otype, restrict, _Static_assert, throw, throwResume, trait, try, ttype, typeof, __typeof, 
-		__typeof__, zero_t},
-	morekeywords=[2]{
-		accept, _Atomic, coroutine, is_coroutine, is_monitor, is_thread, monitor, mutex, nomutex, 
-		resume, signal, signal_block, suspend, thread, _Thread_local, wait, yield},
+		__const, __const__, coroutine, disable, dtype, enable, __extension__, fallthrough, fallthru,
+		finally, forall, ftype, _Generic, _Imaginary, inline, __label__, lvalue, monitor, mutex,
+		_Noreturn, one_t, otype, restrict, _Static_assert, thread, _Thread_local, throw, throwResume,
+		trait, try, ttype, typeof, __typeof, __typeof__, zero_t},
 }
 
Index: doc/proposals/concurrency/.gitignore
===================================================================
--- doc/proposals/concurrency/.gitignore	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ doc/proposals/concurrency/.gitignore	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
@@ -1,22 +1,21 @@
-build/*.aux
-build/*.acn
-build/*.acr
-build/*.alg
-build/*.bbl
-build/*.blg
-build/*.brf
-build/*.dvi
-build/*.glg
-build/*.glo
-build/*.gls
-build/*.idx
-build/*.ind
-build/*.ist
-build/*.log
-build/*.out
-build/*.ps
-build/*.tex
-build/*.toc
-*.pdf
-
-examples
+concurrency.aux
+concurrency.acn
+concurrency.acr
+concurrency.alg
+concurrency.bbl
+concurrency.blg
+concurrency.brf
+concurrency.dvi
+concurrency.glg
+concurrency.glo
+concurrency.gls
+concurrency.idx
+concurrency.ind
+concurrency.ist
+concurrency.log
+concurrency.out
+concurrency.pdf
+concurrency.ps
+version.aux
+monitor.tex
+ext_monitor.tex
Index: doc/proposals/concurrency/Makefile
===================================================================
--- doc/proposals/concurrency/Makefile	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ doc/proposals/concurrency/Makefile	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
@@ -1,25 +1,21 @@
 ## Define the appropriate configuration variables.
 
-TeXLIB = .:./style:./text:./annex:./build:../../LaTeXmacros:../../LaTeXmacros/listings:../../LaTeXmacros/enumitem:~/bibliographies:
-LaTeX  = TEXINPUTS=${TeXLIB} && export TEXINPUTS && latex -halt-on-error -output-directory=build -interaction=nonstopmode
-BibTeX = BIBINPUTS=${TeXLIB} && export BIBINPUTS && bibtex -terse
+TeXLIB = .:../../LaTeXmacros:../../LaTeXmacros/listings:../../LaTeXmacros/enumitem:~/bibliographies:
+LaTeX  = TEXINPUTS=${TeXLIB} && export TEXINPUTS && latex -halt-on-error
+BibTeX = BIBINPUTS=${TeXLIB} && export BIBINPUTS && bibtex
 
 ## Define the text source files.
 
 SOURCES = ${addsuffix .tex, \
-thesis \
-style/style \
-style/cfa-format \
-annex/glossary \
-text/intro \
-text/basics \
-text/concurrency \
-text/parallelism \
+concurrency \
+style \
+cfa-format \
+glossary \
 }
 
-FIGURES = ${addprefix build/, ${addsuffix .tex, \
+FIGURES = ${addsuffix .tex, \
 	monitor \
 	ext_monitor \
-}}
+}
 
 PICTURES = ${addsuffix .pstex, \
@@ -34,5 +30,5 @@
 ## Define the documents that need to be made.
 
-DOCUMENT = thesis.pdf
+DOCUMENT = concurrency.pdf
 
 # Directives #
@@ -41,52 +37,32 @@
 
 clean :
-	@rm -fv ${DOCUMENT} \
-	build/*.acn     \
-	build/*.acr     \
-	build/*.alg     \
-	build/*.aux     \
-	build/*.bbl     \
-	build/*.blg     \
-	build/*.brf     \
-	build/*.cf      \
-	build/*.dvi     \
-	build/*.glg     \
-	build/*.glo     \
-	build/*.gls     \
-	build/*.ist     \
-	build/*.idx     \
-	build/*.ilg     \
-	build/*.ind     \
-	build/*.log     \
-	build/*.out     \
-	build/*.ps      \
-	build/*.pstex_t \
-	build/*.tex     \
-	build/*.toc     \
-
+	rm -f *.bbl *.aux *.dvi *.idx *.ilg *.ind *.brf *.out *.log *.toc *.blg *.pstex_t *.cf *.glg *.glo *.gls *.ist *.acn *.acr *.alg \
+		${FIGURES} ${PICTURES} ${PROGRAMS} ${GRAPHS} ${basename ${DOCUMENT}}.ps ${DOCUMENT}
 
 # File Dependencies #
 
-${DOCUMENT} : build/${basename ${DOCUMENT}}.ps
+${DOCUMENT} : ${basename ${DOCUMENT}}.ps
 	ps2pdf $<
 
-build/${basename ${DOCUMENT}}.ps : build/${basename ${DOCUMENT}}.dvi
+${basename ${DOCUMENT}}.ps : ${basename ${DOCUMENT}}.dvi
 	dvips $< -o $@
 
-build/${basename ${DOCUMENT}}.dvi : Makefile ${GRAPHS} ${PROGRAMS} ${PICTURES} ${FIGURES} ${SOURCES} ${basename ${DOCUMENT}}.tex ../../LaTeXmacros/common.tex ../../LaTeXmacros/indexstyle
-
-	@ if [ ! -r ${basename $@}.ind ] ; then touch ${basename $@}.ind ; fi 				# Conditionally create an empty *.ind (index) file for inclusion until makeindex is run.
-	@ echo "Citation lookup"											# Must have *.aux file containing citations for bibtex
-	@ if [ ! -r ${basename $@}.aux ] ; then ${LaTeX} ${basename ${notdir $@}}.tex ; fi
-	@ echo "Citation Pass 1"
-	@ -${BibTeX} ${basename $@}											# Some citations reference others so run steps again to resolve these citations
-	@ echo "Citation Pass 2"
-	@ ${LaTeX} ${basename ${notdir $@}}.tex
-	@ -${BibTeX} ${basename $@}
-	@ echo "Glossary"
-	makeglossaries -q -s ${basename $@}.ist ${basename $@}						# Make index from *.aux entries and input index at end of document
-	@ echo ".dvi generation"
-	@ -build/bump_ver.sh
-	@ ${LaTeX} ${basename ${notdir $@}}.tex									# Run again to get index title into table of contents
+${basename ${DOCUMENT}}.dvi : Makefile ${GRAPHS} ${PROGRAMS} ${PICTURES} ${FIGURES} ${SOURCES} ${basename ${DOCUMENT}}.tex \
+		../../LaTeXmacros/common.tex ../../LaTeXmacros/indexstyle
+	# Conditionally create an empty *.ind (index) file for inclusion until makeindex is run.
+	if [ ! -r ${basename $@}.ind ] ; then touch ${basename $@}.ind ; fi
+	# Must have *.aux file containing citations for bibtex
+	if [ ! -r ${basename $@}.aux ] ; then ${LaTeX} ${basename $@}.tex ; fi
+	-${BibTeX} ${basename $@}
+	# Some citations reference others so run steps again to resolve these citations
+	${LaTeX} ${basename $@}.tex
+	-${BibTeX} ${basename $@}
+	# Make index from *.aux entries and input index at end of document
+	makeglossaries ${basename $@}
+	#${LaTeX} ${basename $@}.tex
+	# Run again to get index title into table of contents
+	${LaTeX} ${basename $@}.tex
+	-./bump_ver.sh
+	${LaTeX} ${basename $@}.tex
 
 
@@ -96,11 +72,11 @@
 ## Define the default recipes.
 
-build/%.tex : figures/%.fig
+%.tex : %.fig
 	fig2dev -L eepic $< > $@
 
-build/%.ps : figures/%.fig
+%.ps : %.fig
 	fig2dev -L ps $< > $@
 
-build/%.pstex : figures/%.fig
+%.pstex : %.fig
 	fig2dev -L pstex $< > $@
 	fig2dev -L pstex_t -p $@ $< > $@_t
Index: c/proposals/concurrency/annex/glossary.tex
===================================================================
--- doc/proposals/concurrency/annex/glossary.tex	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ 	(revision )
@@ -1,102 +1,0 @@
-\makeglossaries
-
-\longnewglossaryentry{callsite-locking}
-{name={callsite-locking}}
-{
-Locking done by the calling routine. With this technique, a routine calling a monitor routine will aquire the monitor \emph{before} making the call to the actuall routine.
-}
-
-\longnewglossaryentry{entry-point-locking}
-{name={entry-point-locking}}
-{
-Locking done by the called routine. With this technique, a monitor routine called by another routine will aquire the monitor \emph{after} entering the routine body but prior to any other code.
-}
-
-\longnewglossaryentry{group-acquire}
-{name={bulk acquiring}}
-{
-Implicitly acquiring several monitors when entering a monitor.
-}
-
-\longnewglossaryentry{mon-ctx}
-{name={monitor context}}
-{
-The state of the current thread regarding which monitors are owned.
-}
-
-
-\longnewglossaryentry{uthread}
-{name={user-level thread}}
-{
-Threads created and managed inside user-space. Each thread has its own stack and its own thread of execution. User-level threads are insisible to the underlying operating system.
-
-\textit{Synonyms : User threads, Lightweight threads, Green threads, Virtual threads, Tasks.}
-}
-
-\longnewglossaryentry{kthread}
-{name={kernel-level thread}}
-{
-Threads created and managed inside kernel-space. Each thread has its own stack and its own thread of execution. Kernel-level threads are owned, managed and scheduled by the underlying operating system.
-
-\textit{Synonyms : OS threads, Hardware threads, Physical threads.}
-}
-
-\longnewglossaryentry{fiber}
-{name={fiber}}
-{
-Fibers are non-preemptive user-level threads. They share most of the caracteristics of user-level threads except that they cannot be preempted by an other fiber.
-
-\textit{Synonyms : Tasks.}
-}
-
-\longnewglossaryentry{job}
-{name={job}}
-{
-Unit of work, often send to a thread pool or worker pool to be executed. Has neither its own stack or its own thread of execution.
-
-\textit{Synonyms : Tasks.}
-}
-
-\longnewglossaryentry{pool}
-{name={thread-pool}}
-{
-Group of homogeneuous threads that loop executing units of works after another.
-
-\textit{Synonyms : }
-}
-
-\longnewglossaryentry{cfacluster}
-{name={cluster}}
-{
-TBD...
-
-\textit{Synonyms : None.}
-}
-
-\longnewglossaryentry{cfacpu}
-{name={processor}}
-{
-TBD...
-
-\textit{Synonyms : None.}
-}
-
-\longnewglossaryentry{cfathread}
-{name={thread}}
-{
-TBD...
-
-\textit{Synonyms : None.}
-}
-
-\longnewglossaryentry{preemption}
-{name={preemption}}
-{
-TBD...
-
-\textit{Synonyms : None.}
-}
-
-\newacronym{tls}{TLS}{Thread Local Storage}
-\newacronym{api}{API}{Application Program Interface}
-\newacronym{raii}{RAII}{Ressource Acquisition Is Initialization}
Index: c/proposals/concurrency/annex/local.bib
===================================================================
--- doc/proposals/concurrency/annex/local.bib	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ 	(revision )
@@ -1,40 +1,0 @@
-%    Predefined journal names:
-%  acmcs: Computing Surveys		acta: Acta Infomatica
-%  cacm: Communications of the ACM
-%  ibmjrd: IBM J. Research & Development ibmsj: IBM Systems Journal
-%  ieeese: IEEE Trans. on Soft. Eng.	ieeetc: IEEE Trans. on Computers
-%  ieeetcad: IEEE Trans. on Computer-Aided Design of Integrated Circuits
-%  ipl: Information Processing Letters	jacm: Journal of the ACM
-%  jcss: J. Computer & System Sciences	scp: Science of Comp. Programming
-%  sicomp: SIAM J. on Computing		tocs: ACM Trans. on Comp. Systems
-%  tods: ACM Trans. on Database Sys.	tog: ACM Trans. on Graphics
-%  toms: ACM Trans. on Math. Software	toois: ACM Trans. on Office Info. Sys.
-%  toplas: ACM Trans. on Prog. Lang. & Sys.
-%  tcs: Theoretical Computer Science
-@string{ieeepds="IEEE Transactions on Parallel and Distributed Systems"}
-@string{ieeese="IEEE Transactions on Software Engineering"}
-@string{spe="Software---\-Practice and Experience"}
-@string{sigplan="SIGPLAN Notices"}
-@string{joop="Journal of Object-Oriented Programming"}
-@string{popl="Conference Record of the ACM Symposium on Principles of Programming Languages"}
-@string{osr="Operating Systems Review"}
-@string{pldi="Programming Language Design and Implementation"}
-
-
-@article{HPP:Study,
-	keywords 	= {Parallel, Productivity},
-	author 	= {Lorin Hochstein and Jeff Carver and Forrest Shull and Sima Asgari and Victor Basili and Jeffrey K. Hollingsworth and Marvin V. Zelkowitz },
-	title 	= {Parallel Programmer Productivity: A Case Study of Novice Parallel Programmers},
-}
-
-@article{Chicken,
-	keywords	= {Chicken},
-	author	= {Doug Zongker},
-	title		= {Chicken Chicken Chicken: Chicken Chicken},
-	year		= 2006
-}
-
-@article{TBB,
-	keywords 	= {Intel, TBB},
-	title 	= {Intel Thread Building Blocks},
-}
Index: c/proposals/concurrency/build/bump_ver.sh
===================================================================
--- doc/proposals/concurrency/build/bump_ver.sh	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ 	(revision )
@@ -1,6 +1,0 @@
-#!/bin/bash
-if [ ! -f build/version ]; then
-    echo "0.0.0" > build/version
-fi
-
-sed -r 's/([0-9]+\.[0-9]+.)([0-9]+)/echo "\1\$((\2+1))" > version/ge' build/version > /dev/null
Index: c/proposals/concurrency/build/version
===================================================================
--- doc/proposals/concurrency/build/version	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ 	(revision )
@@ -1,1 +1,0 @@
-0.9.117
Index: doc/proposals/concurrency/bump_ver.sh
===================================================================
--- doc/proposals/concurrency/bump_ver.sh	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
+++ doc/proposals/concurrency/bump_ver.sh	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
@@ -0,0 +1,6 @@
+#!/bin/bash
+if [ ! -f version ]; then
+    echo "0.0.0" > version
+fi
+
+sed -r 's/([0-9]+\.[0-9]+.)([0-9]+)/echo "\1\$((\2+1))" > version/ge' version > /dev/null
Index: doc/proposals/concurrency/cfa-format.tex
===================================================================
--- doc/proposals/concurrency/cfa-format.tex	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
+++ doc/proposals/concurrency/cfa-format.tex	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
@@ -0,0 +1,220 @@
+\usepackage{xcolor}
+\usepackage{listings}
+\usepackage{inconsolata}
+
+\definecolor{basicCol}{HTML}{000000}
+\definecolor{commentCol}{HTML}{000000}
+\definecolor{stringCol}{HTML}{000000}
+\definecolor{keywordCol}{HTML}{000000}
+\definecolor{identifierCol}{HTML}{000000}
+
+% from https://gist.github.com/nikolajquorning/92bbbeef32e1dd80105c9bf2daceb89a
+\lstdefinelanguage{sml} {
+  morekeywords= {
+    EQUAL, GREATER, LESS, NONE, SOME, abstraction, abstype, and, andalso, array, as, before, bool, case, char, datatype, do, else, end, eqtype, exception, exn, false, fn, fun, functor, handle, if, in, include, infix, infixr, int, let, list, local, nil, nonfix, not, o, of, op, open, option, orelse, overload, print, raise, real, rec, ref, sharing, sig, signature, string, struct, structure, substring, then, true, type, unit, val, vector, where, while, with, withtype, word
+  },
+  morestring=[b]",
+  morecomment=[s]{(*}{*)},
+}
+
+\lstdefinelanguage{D}{
+  % Keywords
+  morekeywords=[1]{
+    abstract, alias, align, auto, body, break, cast, catch, class, const,
+    continue, debug, delegate, delete, deprecated, do, else, enum, export,
+    false, final, finally, for, foreach, foreach_reverse, function, goto, if,
+    immutable, import, in, inout, interface, invariant, is, lazy, macro, mixin,
+    module, new, nothrow, null, out, override, package, pragma, private,
+    protected, public, pure, ref, return, shared, static, struct, super,
+    switch, synchronized, template, this, throw, true, try, typedef, typeid,
+    typeof, union, unittest, volatile, while, with
+  },
+  % Special identifiers, common functions
+  morekeywords=[2]{enforce},
+  % Ugly identifiers
+  morekeywords=[3]{
+    __DATE__, __EOF__, __FILE__, __LINE__, __TIMESTAMP__, __TIME__, __VENDOR__,
+    __VERSION__, __ctfe, __gshared, __monitor, __thread, __vptr, _argptr,
+    _arguments, _ctor, _dtor
+  },
+  % Basic types
+  morekeywords=[4]{
+     byte, ubyte, short, ushort, int, uint, long, ulong, cent, ucent, void,
+     bool, bit, float, double, real, ushort, int, uint, long, ulong, float,
+     char, wchar, dchar, string, wstring, dstring, ireal, ifloat, idouble,
+     creal, cfloat, cdouble, size_t, ptrdiff_t, sizediff_t, equals_t, hash_t
+  },
+  % Strings
+  morestring=[b]{"},
+  morestring=[b]{'},
+  morestring=[b]{`},
+  % Comments
+  comment=[l]{//},
+  morecomment=[s]{/*}{*/},
+  morecomment=[s][\color{blue}]{/**}{*/},
+  morecomment=[n]{/+}{+/},
+  morecomment=[n][\color{blue}]{/++}{+/},
+  % Options
+  sensitive=true
+}
+
+\lstdefinelanguage{rust}{
+  % Keywords
+  morekeywords=[1]{
+    abstract, alignof, as, become, box,
+    break, const, continue, crate, do,
+    else, enum, extern, false, final,
+    fn, for, if, impl, in,
+    let, loop, macro, match, mod,
+    move, mut, offsetof, override, priv,
+    proc, pub, pure, ref, return,
+    Self, self, sizeof, static, struct,
+    super, trait, true,  type, typeof,
+    unsafe, unsized, use, virtual, where,
+    while, yield
+  },
+  % Strings
+  morestring=[b]{"},
+  % Comments
+  comment=[l]{//},
+  morecomment=[s]{/*}{*/},
+  % Options
+  sensitive=true
+}
+
+\lstdefinelanguage{pseudo}{
+	morekeywords={string,uint,int,bool,float},%
+	sensitive=true,%
+	morecomment=[l]{//},%
+	morecomment=[s]{/*}{*/},%
+	morestring=[b]',%
+	morestring=[b]",%
+	morestring=[s]{`}{`},%
+}%
+
+\newcommand{\KWC}{K-W C\xspace}
+
+\lstdefinestyle{pseudoStyle}{
+  escapeinside={@@},
+  basicstyle=\linespread{0.9}\sf\footnotesize,		% reduce line spacing and use typewriter font
+  keywordstyle=\bfseries\color{blue},
+  keywordstyle=[2]\bfseries\color{Plum},
+  commentstyle=\itshape\color{OliveGreen},		    % green and italic comments
+  identifierstyle=\color{identifierCol},
+  stringstyle=\sf\color{Mahogany},			          % use sanserif font
+  mathescape=true,
+  columns=fixed,
+  aboveskip=4pt,                                  % spacing above/below code block
+  belowskip=3pt,
+  keepspaces=true,
+  % frame=lines,
+  literate=,
+  showlines=true,                                 % show blank lines at end of code
+  showspaces=false,
+  showstringspaces=false,
+  escapechar=\$,
+  xleftmargin=\parindentlnth,                     % indent code to paragraph indentation
+  moredelim=[is][\color{red}\bfseries]{**R**}{**R**},    % red highlighting
+  % moredelim=* detects keywords, comments, strings, and other delimiters and applies their formatting
+  % moredelim=** allows cumulative application
+}
+
+\lstdefinestyle{defaultStyle}{
+  escapeinside={@@},
+  basicstyle=\linespread{0.9}\tt\footnotesize,		% reduce line spacing and use typewriter font
+  keywordstyle=\bfseries\color{blue},
+  keywordstyle=[2]\bfseries\color{Plum},
+  commentstyle=\itshape\color{OliveGreen},		    % green and italic comments
+  identifierstyle=\color{identifierCol},
+  stringstyle=\sf\color{Mahogany},			          % use sanserif font
+  mathescape=true,
+  columns=fixed,
+  aboveskip=4pt,                                  % spacing above/below code block
+  belowskip=3pt,
+  keepspaces=true,
+  % frame=lines,
+  literate=,
+  showlines=true,                                 % show blank lines at end of code
+  showspaces=false,
+  showstringspaces=false,
+  escapechar=\$,
+  xleftmargin=\parindentlnth,                     % indent code to paragraph indentation
+  moredelim=[is][\color{red}\bfseries]{**R**}{**R**},    % red highlighting
+  % moredelim=* detects keywords, comments, strings, and other delimiters and applies their formatting
+  % moredelim=** allows cumulative application
+}
+\lstset{
+  morekeywords=[2]{nomutex,mutex,thread,wait,wait_release,signal,signal_block,accept,monitor,suspend,resume,coroutine}
+  language = CFA,
+  style=defaultStyle
+}
+\lstMakeShortInline[basewidth=0.5em,breaklines=true,basicstyle=\normalsize\ttfamily\color{basicCol}]@  % single-character for \lstinline
+
+\lstnewenvironment{cfacode}[1][]{ %
+  \lstset{ %
+    language = CFA, %
+    style=defaultStyle, %
+    morekeywords=[2]{nomutex,mutex,thread,wait,signal,signal_block,accept,monitor,suspend,resume,coroutine}, %
+    #1 %
+  } %
+}{}
+
+\lstnewenvironment{pseudo}[1][]{
+  \lstset{
+    language = pseudo,
+    style=pseudoStyle,
+    #1
+  }
+}{}
+
+\lstnewenvironment{cppcode}[1][]{
+  \lstset{
+    language = c++,
+    style=defaultStyle,
+    #1
+  }
+}{}
+
+\lstnewenvironment{javacode}[1][]{
+  \lstset{
+    language = java,
+    style=defaultStyle,
+    #1
+  }
+}{}
+
+\lstnewenvironment{scalacode}[1][]{
+  \lstset{
+    language = scala,
+    style=defaultStyle,
+    #1
+  }
+}{}
+
+\lstnewenvironment{smlcode}[1][]{
+  \lstset{
+    language = sml,
+    style=defaultStyle,
+    #1
+  }
+}{}
+
+\lstnewenvironment{dcode}[1][]{
+  \lstset{
+    language = D,
+    style=defaultStyle,
+    #1
+  }
+}{}
+
+\lstnewenvironment{rustcode}[1][]{
+  \lstset{
+    language = rust,
+    style=defaultStyle,
+    #1
+  }
+}{}
+
+\newcommand{\zero}{\lstinline{zero_t}\xspace}
+\newcommand{\one}{\lstinline{one_t}\xspace}
+\newcommand{\ateq}{\lstinline{\@=}\xspace}
Index: doc/proposals/concurrency/concurrency.tex
===================================================================
--- doc/proposals/concurrency/concurrency.tex	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
+++ doc/proposals/concurrency/concurrency.tex	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
@@ -0,0 +1,1644 @@
+% requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
+
+% inline code ©...© (copyright symbol) emacs: C-q M-)
+% red highlighting ®...® (registered trademark symbol) emacs: C-q M-.
+% blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_
+% green highlighting ¢...¢ (cent symbol) emacs: C-q M-"
+% LaTex escape §...§ (section symbol) emacs: C-q M-'
+% keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
+% math escape $...$ (dollar symbol)
+
+\documentclass[letterpaper,12pt,titlepage,oneside,final]{book}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+% Latex packages used in the document.
+\usepackage[T1]{fontenc}					% allow Latin1 (extended ASCII) characters
+\usepackage{textcomp}
+\usepackage[latin1]{inputenc}
+\usepackage{fullpage,times,comment}
+\usepackage{epic,eepic}
+\usepackage{upquote}						% switch curled `'" to straight
+\usepackage{calc}
+\usepackage{xspace}
+\usepackage{graphicx}
+\usepackage{tabularx}
+\usepackage{multicol}
+\usepackage[acronym]{glossaries}
+\usepackage{varioref}	
+\usepackage{listings}						% format program code
+\usepackage[flushmargin]{footmisc}				% support label/reference in footnote
+\usepackage{latexsym}						% \Box glyph
+\usepackage{mathptmx}						% better math font with "times"
+\usepackage[usenames]{color}
+\usepackage[pagewise]{lineno}
+\usepackage{fancyhdr}
+\renewcommand{\linenumberfont}{\scriptsize\sffamily}
+\input{style}							% bespoke macros used in the document
+\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
+\usepackage{breakurl}
+
+\usepackage{tikz}
+\def\checkmark{\tikz\fill[scale=0.4](0,.35) -- (.25,0) -- (1,.7) -- (.25,.15) -- cycle;}
+
+\renewcommand{\UrlFont}{\small\sf}
+
+\setlength{\topmargin}{-0.45in}				% move running title into header
+\setlength{\headsep}{0.25in}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+% Names used in the document.
+
+\newcommand{\Version}{1.0.0}
+\newcommand{\CS}{C\raisebox{-0.9ex}{\large$^\sharp$}\xspace}
+
+\newcommand{\Textbf}[2][red]{{\color{#1}{\textbf{#2}}}}
+\newcommand{\Emph}[2][red]{{\color{#1}\textbf{\emph{#2}}}}
+\newcommand{\R}[1]{\Textbf{#1}}
+\newcommand{\B}[1]{{\Textbf[blue]{#1}}}
+\newcommand{\G}[1]{{\Textbf[OliveGreen]{#1}}}
+\newcommand{\uC}{$\mu$\CC}
+\newcommand{\cit}{\textsuperscript{[Citation Needed]}\xspace}
+\newcommand{\code}[1]{\lstinline[language=CFA]{#1}}
+\newcommand{\pscode}[1]{\lstinline[language=pseudo]{#1}}
+\newcommand{\TODO}{{\Textbf{TODO}}}
+
+\input{glossary}
+
+\newsavebox{\LstBox}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\setcounter{secnumdepth}{3}                             % number subsubsections
+\setcounter{tocdepth}{3}                                % subsubsections in table of contents
+% \linenumbers                                            % comment out to turn off line numbering
+\makeindex
+\pagestyle{fancy}
+\fancyhf{}
+\cfoot{\thepage}
+\rfoot{v\input{version}}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{document}
+% \linenumbers
+
+\title{Concurrency in \CFA}
+\author{Thierry Delisle \\
+School of Computer Science, University of Waterloo, \\ Waterloo, Ontario, Canada
+}
+
+\maketitle
+
+% ### #     # ####### ######  #######
+%  #  ##    #    #    #     # #     #
+%  #  # #   #    #    #     # #     #
+%  #  #  #  #    #    ######  #     #
+%  #  #   # #    #    #   #   #     #
+%  #  #    ##    #    #    #  #     #
+% ### #     #    #    #     # #######
+
+\chapter{Introduction}
+This proposal provides a minimal core concurrency API that is both simple, efficient and can be reused to build higher-level features. The simplest possible concurrency core is a thread and a lock but this low-level approach is hard to master. An easier approach for users is to support higher-level constructs as the basis of the concurrency in \CFA. Indeed, for highly productive parallel programming, high-level approaches are much more popular~\cite{HPP:Study}. Examples are task based, message passing and implicit threading.
+
+There are actually two problems that need to be solved in the design of the concurrency for a programming language: which concurrency tools are available to the users and which parallelism tools are available. While these two concepts are often seen together, they are in fact distinct concepts that require different sorts of tools~\cite{Buhr05a}. Concurrency tools need to handle mutual exclusion and synchronization, while parallelism tools are more about performance, cost and resource utilization.
+
+%  #####  ####### #     #  #####  #     # ######  ######  ####### #     #  #####  #     #
+% #     # #     # ##    # #     # #     # #     # #     # #       ##    # #     #  #   #
+% #       #     # # #   # #       #     # #     # #     # #       # #   # #         # #
+% #       #     # #  #  # #       #     # ######  ######  #####   #  #  # #          #
+% #       #     # #   # # #       #     # #   #   #   #   #       #   # # #          #
+% #     # #     # #    ## #     # #     # #    #  #    #  #       #    ## #     #    #
+%  #####  ####### #     #  #####   #####  #     # #     # ####### #     #  #####     #
+
+\chapter{Concurrency}
+Several tool can be used to solve concurrency challenges. Since these challenges always appear with the use of mutable shared-state, some languages and libraries simply disallow mutable shared-state (Erlang~\cite{Erlang}, Haskell~\cite{Haskell}, Akka (Scala)~\cite{Akka}). In these paradigms, interaction among concurrent objects relies on message passing~\cite{Thoth,Harmony,V-Kernel} or other paradigms that closely relate to networking concepts (channels\cit for example). However, in languages that use routine calls as their core abstraction mechanism, these approaches force a clear distinction between concurrent and non-concurrent paradigms (i.e., message passing versus routine call). Which in turn means that, in order to be effective, programmers need to learn two sets of designs patterns. This distinction can be hidden away in library code, but effective use of the librairy still has to take both paradigms into account. Approaches based on shared memory are more closely related to non-concurrent paradigms since they often rely on basic constructs like routine calls and objects. At a lower level these can be implemented as locks and atomic operations. Many such mechanisms have been proposed, including semaphores~\cite{Dijkstra68b} and path expressions~\cite{Campbell74}. However, for productivity reasons it is desireable to have a higher-level construct be the core concurrency paradigm~\cite{HPP:Study}. An approach that is worth mentionning because it is gaining in popularity is transactionnal memory~\cite{Dice10}[Check citation]. While this approach is even pursued by system languages like \CC\cit, the performance and feature set is currently too restrictive to add such a paradigm to a language like C or \CC\cit, which is why it was rejected as the core paradigm for concurrency in \CFA. One of the most natural, elegant, and efficient mechanisms for synchronization and communication, especially for shared memory systems, is the \emph{monitor}. Monitors were first proposed by Brinch Hansen~\cite{Hansen73} and later described and extended by C.A.R.~Hoare~\cite{Hoare74}. Many programming languages---e.g., Concurrent Pascal~\cite{ConcurrentPascal}, Mesa~\cite{Mesa}, Modula~\cite{Modula-2}, Turing~\cite{Turing:old}, Modula-3~\cite{Modula-3}, NeWS~\cite{NeWS}, Emerald~\cite{Emerald}, \uC~\cite{Buhr92a} and Java~\cite{Java}---provide monitors as explicit language constructs. In addition, operating-system kernels and device drivers have a monitor-like structure, although they often use lower-level primitives such as semaphores or locks to simulate monitors. For these reasons, this project proposes monitors as the core concurrency construct.
+
+% #     # ####### #     # ### ####### ####### ######   #####
+% ##   ## #     # ##    #  #     #    #     # #     # #     #
+% # # # # #     # # #   #  #     #    #     # #     # #
+% #  #  # #     # #  #  #  #     #    #     # ######   #####
+% #     # #     # #   # #  #     #    #     # #   #         #
+% #     # #     # #    ##  #     #    #     # #    #  #     #
+% #     # ####### #     # ###    #    ####### #     #  #####
+
+\section{Monitors}
+A monitor is a set of routines that ensure mutual exclusion when accessing shared state. This concept is generally associated with Object-Oriented Languages like Java~\cite{Java} or \uC~\cite{uC++book} but does not strictly require OOP semantics. The only requirements is the ability to declare a handle to a shared object and a set of routines that act on it :
+\begin{cfacode}
+	typedef /*some monitor type*/ monitor;
+	int f(monitor & m);
+
+	int main() {
+		monitor m;
+		f(m);
+	}
+\end{cfacode}
+
+%  #####     #    #       #
+% #     #   # #   #       #
+% #        #   #  #       #
+% #       #     # #       #
+% #       ####### #       #
+% #     # #     # #       #
+%  #####  #     # ####### #######
+
+\subsection{Call semantics} \label{call}
+The above monitor example displays some of the intrinsic characteristics. Indeed, it is necessary to use pass-by-reference over pass-by-value for monitor routines. This semantics is important because at their core, monitors are implicit mutual-exclusion objects (locks), and these objects cannot be copied. Therefore, monitors are implicitly non-copyable.
+
+Another aspect to consider is when a monitor acquires its mutual exclusion. For example, a monitor may need to be passed through multiple helper routines that do not acquire the monitor mutual-exclusion on entry. Pass through can be both generic helper routines (\code{swap}, \code{sort}, etc.) or specific helper routines like the following to implement an atomic counter :
+
+\begin{cfacode}
+	monitor counter_t { /*...see section $\ref{data}$...*/ };
+
+	void ?{}(counter_t & nomutex this); //constructor
+	size_t ++?(counter_t & mutex this); //increment
+
+	//need for mutex is platform dependent here
+	void ?{}(size_t * this, counter_t & mutex cnt); //conversion
+\end{cfacode}
+
+Here, the constructor(\code{?\{\}}) uses the \code{nomutex} keyword to signify that it does not acquire the monitor mutual exclusion when constructing. This semantics is because an object not yet constructed should never be shared and therefore does not require mutual exclusion. The prefix increment operator uses \code{mutex} to protect the incrementing process from race conditions. Finally, there is a conversion operator from \code{counter_t} to \code{size_t}. This conversion may or may not require the \code{mutex} key word depending on whether or not reading an \code{size_t} is an atomic operation or not.
+
+Having both \code{mutex} and \code{nomutex} keywords could be argued to be redundant based on the meaning of a routine having neither of these keywords. For example, given a routine without quualifiers \code{void foo(counter_t & this)} then one could argue that it should default to the safest option \code{mutex}. On the other hand, the option of having routine \code{void foo(counter_t & this)} mean \code{nomutex} is unsafe by default and may easily cause subtle errors. It can be argued that \code{nomutex} is the more "normal" behaviour, the \code{nomutex} keyword effectively stating explicitly that "this routine has nothing special". Another alternative is to make having exactly one of these keywords mandatory, which would provide the same semantics but without the ambiguity of supporting routine \code{void foo(counter_t & this)}. Mandatory keywords would also have the added benefice of being self-documented but at the cost of extra typing. However, since \CFA relies heavily on traits as an abstraction mechanism, the distinction between a type that is a monitor and a type that looks like a monitor can become blurred. For this reason, \CFA only has the \code{mutex} keyword.
+
+
+The next semantic decision is to establish when \code{mutex} may be used as a type qualifier. Consider the following declarations:
+\begin{cfacode}
+	int f1(monitor & mutex m);
+	int f2(const monitor & mutex m);
+	int f3(monitor ** mutex m);
+	int f4(monitor *[] mutex m);
+	int f5(graph(monitor*) & mutex m);
+\end{cfacode}
+The problem is to indentify which object(s) should be acquired. Furthermore, each object needs to be acquired only once. In the case of simple routines like \code{f1} and \code{f2} it is easy to identify an exhaustive list of objects to acquire on entry. Adding indirections (\code{f3}) still allows the compiler and programmer to indentify which object is acquired. However, adding in arrays (\code{f4}) makes it much harder. Array lengths are not necessarily known in C and even then making sure we only acquire objects once becomes also none trivial. This can be extended to absurd limits like \code{f5}, which uses a graph of monitors. To keep everyone as sane as possible~\cite{Chicken}, this projects imposes the requirement that a routine may only acquire one monitor per parameter and it must be the type of the parameter with one level of indirection (ignoring potential qualifiers). Also note that while routine \code{f3} can be supported, meaning that monitor \code{**m} is be acquired, passing an array to this routine would be type safe and yet result in undefined behavior because only the first element of the array is acquired. However, this ambiguity is part of the C type system with respects to arrays. For this reason, \code{mutex} is disallowed in the context where arrays may be passed.
+
+Finally, for convenience, monitors support multiple acquireing, that is acquireing a monitor while already holding it does not cause a deadlock. It simply increments an internal counter which is then used to release the monitor after the number of acquires and releases match up.
+
+% ######     #    #######    #
+% #     #   # #      #      # #
+% #     #  #   #     #     #   #
+% #     # #     #    #    #     #
+% #     # #######    #    #######
+% #     # #     #    #    #     #
+% ######  #     #    #    #     #
+
+\subsection{Data semantics} \label{data}
+Once the call semantics are established, the next step is to establish data semantics. Indeed, until now a monitor is used simply as a generic handle but in most cases monitors contian shared data. This data should be intrinsic to the monitor declaration to prevent any accidental use of data without its appropriate protection. For example, here is a complete version of the counter showed in section \ref{call}:
+\begin{cfacode}
+	monitor counter_t {
+		int value;
+	};
+
+	void ?{}(counter_t & this) {
+		this.cnt = 0;
+	}
+
+	int ++?(counter_t & mutex this) {
+		return ++this.value;
+	}
+
+	//need for mutex is platform dependent here
+	void ?{}(int * this, counter_t & mutex cnt) {
+		*this = (int)cnt;
+	}
+\end{cfacode}
+
+This simple counter is used as follows:
+\begin{center}
+\begin{tabular}{c @{\hskip 0.35in} c @{\hskip 0.35in} c}
+\begin{cfacode}
+	//shared counter
+	counter_t cnt;
+
+	//multiple threads access counter
+	thread 1 : cnt++;
+	thread 2 : cnt++;
+	thread 3 : cnt++;
+	  ...
+	thread N : cnt++;
+\end{cfacode}
+\end{tabular}
+\end{center}
+
+Notice how the counter is used without any explicit synchronisation and yet supports thread-safe semantics for both reading and writting. Unlike object-oriented monitors, where calling a mutex member \emph{implicitly} acquires mutual-exclusion, \CFA uses an explicit mechanism to acquire mutual-exclusion. A consequence of this approach is that it extends to multi-monitor calls.
+\begin{cfacode}
+	int f(MonitorA & mutex a, MonitorB & mutex b);
+
+	MonitorA a;
+	MonitorB b;
+	f(a,b);
+\end{cfacode}
+This code acquires both locks before entering the critical section, called \emph{\gls{group-acquire}}. In practice, writing multi-locking routines that do not lead to deadlocks is tricky. Having language support for such a feature is therefore a significant asset for \CFA. In the case presented above, \CFA guarantees that the order of aquisition is consistent across calls to routines using the same monitors as arguments. However, since \CFA monitors use multi-acquisition locks, users can effectively force the acquiring order. For example, notice which routines use \code{mutex}/\code{nomutex} and how this affects aquiring order :
+\begin{cfacode}
+	void foo(A & mutex a, B & mutex b) { //acquire a & b
+		//...
+	}
+
+	void bar(A & mutex a, B & /*nomutex*/ b) { //acquire a
+		//...
+		foo(a, b); //acquire b
+		//...
+	}
+
+	void baz(A & /*nomutex*/ a, B & mutex b) { //acquire b
+		//...
+		foo(a, b); //acquire a
+		//...
+	}
+\end{cfacode}
+
+The multi-acquisition monitor lock allows a monitor lock to be acquired by both \code{bar} or \code{baz} and acquired again in \code{foo}. In the calls to \code{bar} and \code{baz} the monitors are acquired in opposite order. such use leads to nested monitor call problems~\cite{Lister77}, which is a more specific variation of the lock acquiring order problem. In the example above, the user uses implicit ordering in the case of function \code{foo} but explicit ordering in the case of \code{bar} and \code{baz}. This subtle mistake means that calling these routines concurrently may lead to deadlock and is therefore undefined behavior. As shown on several occasion\cit, solving this problem requires :
+\begin{enumerate}
+	\item Dynamically tracking of the monitor-call order.
+	\item Implement rollback semantics.
+\end{enumerate}
+
+While the first requirement is already a significant constraint on the system, implementing a general rollback semantics in a C-like language is prohibitively complex \cit. In \CFA, users simply need to be carefull when acquiring multiple monitors at the same time.
+
+% ######  ####### #######    #    ### #        #####
+% #     # #          #      # #    #  #       #     #
+% #     # #          #     #   #   #  #       #
+% #     # #####      #    #     #  #  #        #####
+% #     # #          #    #######  #  #             #
+% #     # #          #    #     #  #  #       #     #
+% ######  #######    #    #     # ### #######  #####
+%
+% 	      ######  ####### #       #     # #     # ####### ######  #     #
+% 	      #     # #     # #        #   #  ##   ## #     # #     # #     #
+% 	      #     # #     # #         # #   # # # # #     # #     # #     #
+%  #####    ######  #     # #          #    #  #  # #     # ######  #######
+% 	      #       #     # #          #    #     # #     # #   #   #     #
+% 	      #       #     # #          #    #     # #     # #    #  #     #
+% 	      #       ####### #######    #    #     # ####### #     # #     #
+
+\subsection{Implementation Details: Interaction with polymorphism}
+At first glance, interaction between monitors and \CFA's concept of polymorphism seems complex to support. However, it is shown that entry-point locking can solve most of the issues.
+
+Before looking into complex control flow, it is important to present the difference between the two acquiring options : \gls{callsite-locking} and \gls{entry-point-locking}, i.e. acquiring the monitors before making a mutex call or as the first instruction of the mutex call. For example:
+
+\begin{center}
+\begin{tabular}{|c|c|c|}
+Code & \gls{callsite-locking} & \gls{entry-point-locking} \\
+\CFA & pseudo-code & pseudo-code \\
+\hline
+\begin{cfacode}[tabsize=3]
+void foo(monitor& mutex a){
+
+
+
+	//Do Work
+	//...
+
+}
+
+void main() {
+	monitor a;
+
+
+
+	foo(a);
+
+}
+\end{cfacode} & \begin{pseudo}[tabsize=3]
+foo(& a) {
+
+
+
+	//Do Work
+	//...
+
+}
+
+main() {
+	monitor a;
+	//calling routine
+	//handles concurrency
+	acquire(a);
+	foo(a);
+	release(a);
+}
+\end{pseudo} & \begin{pseudo}[tabsize=3]
+foo(& a) {
+	//called routine
+	//handles concurrency
+	acquire(a);
+	//Do Work
+	//...
+	release(a);
+}
+
+main() {
+	monitor a;
+
+
+
+	foo(a);
+
+}
+\end{pseudo}
+\end{tabular}
+\end{center}
+
+First of all, interaction between \code{otype} polymorphism and monitors is impossible since monitors do not support copying. Therefore, the main question is how to support \code{dtype} polymorphism. Since a monitor's main purpose is to ensure mutual exclusion when accessing shared data, this implies that mutual exclusion is only required for routines that do in fact access shared data. However, since \code{dtype} polymorphism always handles incomplete types (by definition), no \code{dtype} polymorphic routine can access shared data since the data requires knowledge about the type. Therefore, the only concern when combining \code{dtype} polymorphism and monitors is to protect access to routines. \Gls{callsite-locking} would require a significant amount of work, since any \code{dtype} routine may have to obtain some lock before calling a routine, depending on whether or not the type passed is a monitor. However, with \gls{entry-point-locking} calling a monitor routine becomes exactly the same as calling it from anywhere else. Note that the \code{mutex} keyword relies on the resolver, which mean that in cases where generic monitor routines is actually desired, writing mutex routine is possible with the proper trait.
+
+
+% ### #     # #######         #####   #####  #     # ####### ######
+%  #  ##    #    #           #     # #     # #     # #       #     #
+%  #  # #   #    #           #       #       #     # #       #     #
+%  #  #  #  #    #            #####  #       ####### #####   #     #
+%  #  #   # #    #    ###          # #       #     # #       #     #
+%  #  #    ##    #    ###    #     # #     # #     # #       #     #
+% ### #     #    #    ###     #####   #####  #     # ####### ######
+
+\section{Internal scheduling} \label{insched}
+In addition to mutual exclusion, the monitors at the core of \CFA's concurrency can also be used to achieve synchronisation. With monitors, this is generally achieved with internal or external scheduling as in\cit. Since internal scheduling of single monitors is mostly a solved problem, this proposal concentraits on extending internal scheduling to multiple monitors at once. Indeed, like the \gls{group-acquire} semantics, internal scheduling extends to multiple monitors at once in a way that is natural to the user but requires additional complexity on the implementation side.
+
+First, Here is a simple example of such a technique :
+
+\begin{cfacode}
+	monitor A {
+		condition e;
+	}
+
+	void foo(A & mutex a) {
+		// ...
+		// We need someone else to do something now
+		wait(a.e);
+		// ...
+	}
+
+	void bar(A & mutex a) {
+		// Do the thing foo is waiting on
+		// ...
+		// Signal foo it's done
+		signal(a.e);
+	}
+\end{cfacode}
+
+Note that in \CFA, \code{condition} have no particular need to be stored inside a monitor, beyond any software engineering reasons. Here routine \code{foo} waits for the \code{signal} from \code{bar} before making further progress, effectively ensuring a basic ordering. An important aspect to take into account here is that \CFA does not allow barging, which means that once function \code{bar} releases the monitor, foo is guaranteed to resume immediately after (unless some other function waited on the same condition). This guarantees offers the benefit of not having to loop arount waits in order to guarantee that a condition is still met. The main reason \CFA offers this guarantee is that users can easily introduce barging if it becomes a necessity but adding a barging prevention or barging avoidance is more involved without language support.
+
+Supporting barging prevention as well as extending internal scheduling to multiple monitors is the main source of complexity in the design of \CFA concurrency.
+
+\subsection{Internal Scheduling - multi monitor}
+It easier to understand the problem of multi monitor scheduling using a series of pseudo code though experiment. Note that in the following snippets of pseudo-code waiting and signalling is done without the use of a condition variable. While \CFA requires condition variables to use signalling, the variable itself only really holds the data needed for the implementation of internal schedulling. Some languages like JAVA\cit simply define an implicit condition variable for every monitor while other languages like \uC use explicit condition variables. Since the following pseudo-codes are simple and focused experiments, all condition variables are implicit.
+
+\begin{multicols}{2}
+\begin{pseudo}
+acquire A
+	wait A
+release A
+\end{pseudo}
+
+\columnbreak
+
+\begin{pseudo}
+acquire A
+	signal A
+release A
+\end{pseudo}
+\end{multicols}
+
+The previous example shows the simple case of having two threads (one for each column) and a single monitor A. One thread acquires before waiting and the other acquires before signalling. There are a few important things to note here. First, both \code{wait} and \code{signal} must be called with the proper monitor(s) already acquired. This can be hidden on the user side but is a logical requirement for barging prevention. Secondly, as stated above, while it is argued that not all problems regarding single monitors are solved, this paper only regards challenges of \gls{group-acquire} and considers other problems related to monitors as solved.
+
+An important note about this example is that signalling a monitor is a delayed operation. The ownership of the monitor is transferred only when the monitor would have otherwise been released, not at the point of the \code{signal} statement.
+
+A direct extension of the previous example is the \gls{group-acquire} version :
+
+\begin{multicols}{2}
+\begin{pseudo}
+acquire A & B
+	wait A & B
+release A & B
+\end{pseudo}
+
+\columnbreak
+
+\begin{pseudo}
+acquire A & B
+	signal A & B
+release A & B
+\end{pseudo}
+\end{multicols}
+
+This version uses \gls{group-acquire} (denoted using the \& symbol), but the presence of multiple monitors does not add a particularly new meaning. Synchronization will happen between the two threads in exactly the same way and order. The only difference is that mutual exclusion will cover more monitors. On the implementation side, handling multiple monitors at once does add a degree of complexity but it is not significant compared to the next few examples.
+
+For the sake of completeness, here is another example of the single-monitor case, this time with nesting. 
+
+\begin{multicols}{2}
+\begin{pseudo}
+acquire A
+	acquire B
+		wait B
+	release B
+release A
+\end{pseudo}
+
+\columnbreak
+
+\begin{pseudo}
+
+acquire B
+	signal B
+release B
+
+\end{pseudo}
+\end{multicols}
+
+While these cases can cause some deadlock issues, we consider that these issues are only a symptom of the fact that locks, and by extension monitors, are not perfectly composable. However, for monitors as for locks, it is possible to write program that using nesting without encountering any problems if they are nested carefully.
+
+The next example is where \gls{group-acquire} adds a significant layer of complexity to the internal signalling semantics.
+
+\begin{multicols}{2}
+\begin{pseudo}
+acquire A
+	// Code Section 1
+	acquire A & B
+		// Code Section 2
+		wait A & B
+		// Code Section 3
+	release A & B
+	// Code Section 4
+release A
+\end{pseudo}
+
+\columnbreak
+
+\begin{pseudo}
+acquire A
+	// Code Section 5
+	acquire A & B
+		// Code Section 6
+		signal A & B
+		// Code Section 7
+	release A & B
+	// Code Section 8
+release A
+\end{pseudo}
+\end{multicols}
+
+It is particularly important to pay attention to code sections 8 and 3 which are where the existing semantics of internal scheduling are undefined. The root of the problem is that \gls{group-acquire} is used in a context where one of the monitors is already acquired. As mentionned in previous sections, monitors support multiple acquiring which means the that nesting \gls{group-acquire} can be done safely. However, in the context of internal scheduling it is important to define the behaviour of the previous pseudo-code. When the signaller thread reaches the location where it should "release A \& B", it actually only needs to release the monitor B. Since the other thread is waiting on monitor B, the signaller thread cannot simply release the monitor into the wild. This would mean that the waiting thread would have to reacquire the monitor and would therefore open the door to barging threads. Since the signalling thread still needs the monitor A, simply transferring ownership to the waiting thread is not an option because it would pottentially violate mutual exclusion. We are therefore left with three options :
+
+\subsubsection{Delaying signals}
+The first more obvious solution to solve the problem of multi-monitor scheduling is to keep ownership of all locks until the last lock is ready to be transferred. It can be argued that that moment is the correct time to transfer ownership when the last lock is no longer needed is what fits most closely to the behaviour of single monitor scheduling. However, this solution can become much more complicated depending on the content of the code section 8. Indeed, nothing prevents a user from signalling monitor A on a different condition variable. In that case, if monitor B is transferred with monitor A, then it means the system needs to handle threads having ownership on more monitors than expected and how to tie monitors together. On the other hand if the signalling thread only transfers monitor A then somehow both monitors A and B have to be transferred to the waiting thread from two different threads. While this solution may work, it was not fully explored because there is no apparent upper bound on the complexity of ownership transfer.
+
+\subsubsection{Dependency graphs}
+In the previous pseudo-code, there is a solution which would statisfy both barging prevention and mutual exclusion. If ownership of both monitors is transferred to the waiter when the signaller releases A and then the waiter transfers back ownership of A when it releases it then the problem is solved. This is the second solution. The problem it encounters is that it effectively boils down to resolving a dependency graph of ownership requirements. Here even the simplest of code snippets requires two transfers and it seems to increase in a manner closer to polynomial. For example the following code which is just a direct extension to three monitors requires at least three ownership transfer and has multiple solutions. 
+
+\begin{multicols}{2}
+\begin{pseudo}
+acquire A
+	acquire B
+		acquire C
+			wait A & B & C
+		release C
+	release B
+release A
+\end{pseudo}
+
+\columnbreak
+
+\begin{pseudo}
+acquire A
+	acquire B
+		acquire C
+			signal A & B & C
+		release C
+	release B
+release A
+\end{pseudo}
+\end{multicols}
+
+\subsubsection{Partial signalling}
+Finally, the solution that was chosen for \CFA is to use partial signalling. Consider the following case :
+
+\begin{multicols}{2}
+\begin{pseudo}[numbers=left]
+acquire A
+	acquire A & B
+		wait A & B
+	release A & B
+release A
+\end{pseudo}
+
+\columnbreak
+
+\begin{pseudo}[numbers=left, firstnumber=6]
+acquire A
+	acquire A & B
+		signal A & B
+	release A & B
+	// ... More code
+release A
+\end{pseudo}
+\end{multicols}
+
+The partial signalling solution transfers ownership of monitor B at lines 10 but does not wake the waiting thread since it is still using monitor A. Only when it reaches line 11 does it actually wakeup the waiting thread. This solution has the benefit that complexity is encapsulated in to only two actions, passing monitors to the next owner when they should be release and conditionnaly waking threads if all conditions are met. Contrary to the other solutions, this solution quickly hits an upper bound on complexity of implementation.
+
+% Hard extension :
+
+% Incorrect options for the signal : 
+
+% \begin{description}
+%  \item[-] Release B and baton pass after Code Section 8 : Passing b without having it
+%  \item[-] Keep B during Code Section 8 : Can lead to deadlocks since we secretly keep a lock longer than specified by the user
+%  \item[-] Instead of release B transfer A and B to waiter then try to reacquire A before running Code Section 8 : This allows barging 
+% \end{description}
+
+% Since we don't want barging we need to pass A \& B and somehow block and get A back.
+
+% \begin{center}
+% \begin{tabular}{ c @{\hskip 0.65in} c }
+% \begin{lstlisting}[language=Pseudo]
+% acquire A
+% 	acquire B
+% 		acquire C
+% 			wait A & B & C
+% 		1: release C
+% 	2: release B
+% 3: release A
+% \end{lstlisting}&\begin{lstlisting}[language=Pseudo]
+% acquire A
+% 	acquire B
+% 		acquire C
+% 			signal A & B & C
+% 		4: release C
+% 	5: release B
+% 6: release A
+% \end{lstlisting}
+% \end{tabular}
+% \end{center}
+
+% To prevent barging :
+
+% \begin{description}
+%  \item[-] When the signaller hits 4 : pass A, B, C to waiter
+%  \item[-] When the waiter hits 2 : pass A, B to signaller
+%  \item[-] When the signaller hits 5 : pass A to waiter
+% \end{description}
+
+
+% \begin{center}
+% \begin{tabular}{ c @{\hskip 0.65in} c }
+% \begin{lstlisting}[language=Pseudo]
+% acquire A
+% 	acquire C
+% 		acquire B
+% 			wait A & B & C
+% 		1: release B
+% 	2: release C
+% 3: release A
+% \end{lstlisting}&\begin{lstlisting}[language=Pseudo]
+% acquire B
+% 	acquire A
+% 		acquire C
+% 			signal A & B & C
+% 		4: release C
+% 	5: release A
+% 6: release B
+% \end{lstlisting}
+% \end{tabular}
+% \end{center}
+
+% To prevent barging : When the signaller hits 4 : pass A, B, C to waiter. When the waiter hits 1 it must release B, 
+
+% \begin{description}
+%  \item[-] 
+%  \item[-] When the waiter hits 1 : pass A, B to signaller
+%  \item[-] When the signaller hits 5 : pass A, B to waiter
+%  \item[-] When the waiter hits 2 : pass A to signaller
+% \end{description}
+
+% Monitors also need to schedule waiting threads internally as a mean of synchronization. Internal scheduling is one of the simple examples of such a feature. It allows users to declare condition variables and have threads wait and signaled from them. Here is a simple example of such a technique :
+
+% \begin{lstlisting}
+% 	mutex struct A {
+% 		condition e;
+% 	}
+
+% 	void foo(A & mutex a) {
+% 		//...
+% 		wait(a.e);
+% 		//...
+% 	}
+
+% 	void bar(A & mutex a) {
+% 		signal(a.e);
+% 	}
+% \end{lstlisting}
+
+% Note that in \CFA, \code{condition} have no particular need to be stored inside a monitor, beyond any software engineering reasons. Here routine \code{foo} waits for the \code{signal} from \code{bar} before making further progress, effectively ensuring a basic ordering. 
+
+% As for simple mutual exclusion, these semantics must also be extended to include \gls{group-acquire} :
+% \begin{center}
+% \begin{tabular}{ c @{\hskip 0.65in} c }
+% Thread 1 & Thread 2 \\
+% \begin{lstlisting}
+% void foo(A & mutex a,
+%            A & mutex b) {
+% 	//...
+% 	wait(a.e);
+% 	//...
+% }
+
+% foo(a, b);
+% \end{lstlisting} &\begin{lstlisting}
+% void bar(A & mutex a,
+%            A & mutex b) {
+% 	signal(a.e);
+% }
+
+
+
+% bar(a, b);
+% \end{lstlisting}
+% \end{tabular}
+% \end{center}
+
+% To define the semantics of internal scheduling, it is important to look at nesting and \gls{group-acquire}. Indeed, beyond concerns about lock ordering, without scheduling the two following pseudo codes are mostly equivalent. In fact, if we assume monitors are ordered alphabetically, these two pseudo codes would probably lead to exactly the same implementation :
+
+% \begin{table}[h!]
+% \centering
+% \begin{tabular}{c c}
+% \begin{lstlisting}[language=pseudo]
+% monitor A, B, C
+
+% acquire A
+% 	acquire B & C
+
+% 			//Do stuff
+
+% 	release B & C
+% release A
+% \end{lstlisting} &\begin{lstlisting}[language=pseudo]
+% monitor A, B, C
+
+% acquire A
+% 	acquire B
+% 		acquire C
+% 			//Do stuff
+% 		release C
+% 	release B
+% release A
+% \end{lstlisting}
+% \end{tabular}
+% \end{table}
+
+% Once internal scheduling is introduce however, semantics of \gls{group-acquire} become relevant. For example, let us look into the semantics of the following pseudo-code :
+
+% \begin{lstlisting}[language=Pseudo]
+% 1: monitor A, B, C
+% 2: condition c1
+% 3: 
+% 4: acquire A
+% 5: 		acquire A & B & C
+% 6: 				signal c1
+% 7: 		release A & B & C
+% 8: release A
+% \end{lstlisting}
+
+% Without \gls{group-acquire} signal simply baton passes the monitor lock on the next release. In the case above, we therefore need to indentify the next release. If line 8 is picked at the release point, then the signal will attempt to pass A \& B \& C, without having ownership of B \& C. Since this violates mutual exclusion, we conclude that line 7 is the only valid location where signalling can occur. The traditionnal meaning of signalling is to transfer ownership of the monitor(s) and immediately schedule the longest waiting task. However, in the discussed case, the signalling thread expects to maintain ownership of monitor A. This can be expressed in two differents ways : 1) the thread transfers ownership of all locks and reacquires A when it gets schedulled again or 2) it transfers ownership of all three monitors and then expects the ownership of A to be transferred back. 
+
+% However, the question is does these behavior motivate supporting acquireing non-disjoint set of monitors. Indeed, if the previous example was modified to only acquire B \& C at line 5 (an release the accordingly) then in respects to scheduling, we could add the simplifying constraint that all monitors in a bulk will behave the same way, simplifying the problem back to a single monitor problem which has already been solved. For this constraint to be acceptble however, we need to demonstrate that in does not prevent any meaningful possibilities. And, indeed, we can look at the two previous interpretation of the above pseudo-code and conclude that supporting the acquiring of non-disjoint set of monitors does not add any expressiveness to the language.
+
+% Option 1 reacquires the lock after the signal statement, this can be rewritten as follows without the need for non-disjoint sets :
+% \begin{lstlisting}[language=Pseudo]
+% monitor A, B, C
+% condition c1
+
+% acquire A & B & C
+% 	signal c1
+% release A & B & C
+% acquire A
+
+% release A
+% \end{lstlisting}
+
+% This pseudo code has almost exaclty the same semantics as the code acquiring intersecting sets of monitors. 
+
+% Option 2 uses two-way lock ownership transferring instead of reacquiring monitor A. Two-way monitor ownership transfer is normally done using signalBlock semantics, which immedietely transfers ownership of a monitor before getting the ownership back when the other thread no longer needs the monitor. While the example pseudo-code for Option 2 seems toe transfer ownership of A, B and C and only getting A back, this is not a requirement. Getting back all 3 monitors and releasing B and C differs only in performance. For this reason, the second option could arguably be rewritten as : 
+
+% \begin{lstlisting}[language=Pseudo]
+% monitor A, B, C
+% condition c1
+
+% acquire A
+% 	acquire B & C
+% 		signalBlock c1
+% 	release B & C
+% release A
+% \end{lstlisting}
+
+% Obviously, the difference between these two snippets of pseudo code is that the first one transfers ownership of A, B and C while the second one only transfers ownership of B and C. However, this limitation can be removed by allowing user to release extra monitors when using internal scheduling, referred to as extended internal scheduling (pattent pending) from this point on. Extended internal scheduling means the two following pseudo-codes are functionnaly equivalent : 
+% \begin{table}[h!]
+% \centering
+% \begin{tabular}{c @{\hskip 0.65in} c}
+% \begin{lstlisting}[language=pseudo]
+% monitor A, B, C
+% condition c1
+
+% acquire A
+% 	acquire B & C
+% 		signalBlock c1 with A
+% 	release B & C
+% release A
+% \end{lstlisting} &\begin{lstlisting}[language=pseudo]
+% monitor A, B, C
+% condition c1
+
+% acquire A
+% 	acquire A & B & C
+% 		signal c1
+% 	release A & B & C
+% release A
+% \end{lstlisting}
+% \end{tabular}
+% \end{table}
+
+% It must be stated that the extended internal scheduling only makes sense when using wait and signalBlock, since they need to prevent barging, which cannot be done in the context of signal since the ownership transfer is strictly one-directionnal. 
+
+% One critic that could arise is that extended internal schedulling is not composable since signalBlock must be explicitly aware of which context it is in. However, this argument is not relevant since acquire A, B and C in a context where a subset of them is already acquired cannot be achieved without spurriously releasing some locks or having an oracle aware of all monitors. Therefore, composability of internal scheduling is no more an issue than composability of monitors in general.
+
+% The main benefit of using extended internal scheduling is that it offers the same expressiveness as intersecting monitor set acquiring but greatly simplifies the selection of a leader (or representative) for a group of monitor. Indeed, when using intersecting sets, it is not obvious which set intersects with other sets which means finding a leader representing only the smallest scope is a hard problem. Where as when using disjoint sets, any monitor that would be intersecting must be specified in the extended set, the leader can be chosen as any monitor in the primary set.
+
+% We need to make sure the semantics for internally scheduling N monitors are a natural extension of the single monitor semantics. For this reason, we introduce the concept of \gls{mon-ctx}. In terms of context internal scheduling means "releasing a \gls{mon-ctx} and waiting for an other thread to acquire the same \gls{mon-ctx} and baton-pass it back to the initial thread". This definitions requires looking into what a \gls{mon-ctx} is and what the semantics of waiting and baton-passing are.
+
+% \subsubsection{Internal scheduling: Context} \label{insched-context}
+% Monitor scheduling operations are defined in terms of the context they are in. In languages that only supports operations on a single monitor at once, the context is completly defined by which most recently acquired monitors. Indeed, acquiring several monitors will form a stack of monitors which will be released in FILO order. In \CFA, a \gls{mon-ctx} cannot be simply defined by the last monitor that was acquired since \gls{group-acquire} means multiple monitors can be "the last monitor acquired". The \gls{mon-ctx} is therefore defined as the last set of monitors to have been acquired. This means taht when any new monitor is acquired, the group it belongs to is the new \gls{mon-ctx}. Correspondingly, if any monitor is released, the \gls{mon-ctx} reverts back to the context that was used prior to the monitor being acquired. In the most common case, \gls{group-acquire} means every monitor of a group will be acquired in released at the same time. However, since every monitor has its own recursion level, \gls{group-acquire} does not prevent users from reacquiring certain monitors while acquireing new monitors in the same operation. For example :
+
+% \begin{lstlisting}
+% //Forward declarations
+% monitor a, b, c
+% void foo( monitor & mutex a, 
+%             monitor & mutex b);
+% void bar( monitor & mutex a, 
+%             monitor & mutex b);
+% void baz( monitor & mutex a, 
+%             monitor & mutex b, 
+%             monitor & mutex c);
+
+% //Routines defined inline to illustrate context changed compared to the stack
+
+% //main thread
+% foo(a, b) {
+% 	//thread calls foo
+% 	//acquiring context a & b
+
+% 	baz(a, b) {
+% 		//thread calls baz
+% 		//no context change
+
+% 		bar(a, b, c) {
+% 			//thread calls bar
+% 			//acquiring context a & b & c
+
+% 			//Do stuff
+
+% 			return;              
+% 			//call to bar returns
+% 		}
+% 		//context back to a & b
+
+% 		return;
+% 		//call to baz returns
+% 	}
+% 	//no context change
+
+% 	return;
+% 	//call to foo returns
+% }
+% //context back to initial state
+
+% \end{lstlisting}
+
+% As illustrated by the previous example, context changes can be caused by only one of the monitors comming into context or going out of context.
+
+% \subsubsection{Internal scheduling: Waiting} \label{insched-wait}
+
+% \subsubsection{Internal scheduling: Baton Passing} \label{insched-signal}
+% Baton passing in internal scheduling is done in terms of \code{signal} and \code{signalBlock}\footnote{Arguably, \code{signal_now} is a more evocative name and \code{signal} could be changed appropriately. }. While \code{signalBlock} is the more straight forward way of baton passing, transferring ownership immediately, it must rely on \code{signal} which is why t is discussed first.
+% \code{signal} has for effect to transfer the current context to another thread when the context would otherwise be released. This means that instead of releasing the concerned monitors, the first thread on the condition ready-queue is scheduled to run. The monitors are not released and when the signalled thread runs, it assumes it regained ownership of all the monitors it had in its context.
+
+% \subsubsection{Internal scheduling: Implementation} \label{insched-impl}
+% Too implement internal scheduling, three things are need : a data structure for waiting tasks, a data structure for signalled task and a leaving procedure to run the signalled task. In the case of both data structures, it is desireable to have to use intrusive data structures in order to prevent the need for any dynamic allocation. However, in both cases being able to queue several items in the same position in a queue is non trivial, even more so in the presence of concurrency. However, within a given \gls{mon-ctx}, all monitors have exactly the same behavior in regards to scheduling. Therefore, the problem of queuing multiple monitors at once can be ignored by choosing one monitor to represent every monitor in a context. While this could prove difficult in other situations, \gls{group-acquire} requires that the monitors be sorted according to some stable predicate. Since monitors are sorted in all contexts, the representative can simply be the first in the list. Choosing a representative means a simple intrusive queue inside the condition is sufficient to implement the data structure for both waiting and signalled monitors. 
+
+% Since \CFA monitors don't have a complete image of the \gls{mon-ctx}, choosing the representative and maintaning the current context information cannot easily be done by any single monitors. However, as discussed in section [Missing section here], monitor mutual exclusion is implemented using an raii object which is already in charge of sorting monitors. This object has a complete picture of the \gls{mon-ctx} which means it is well suited to choose the reprensentative and detect context changes. 
+
+% \newpage
+% \begin{lstlisting}
+% void ctor( monitor ** _monitors, int _count ) {
+% 	bool ctx_changed = false;
+% 	for( mon in _monitors ) {
+% 		ctx_changed = acquire( mon ) || ctx_changed;
+% 	}
+
+% 	if( ctx_changed ) {
+% 		set_representative();
+% 		set_context();
+% 	}
+% }
+
+% void dtor( monitor ** _monitors, int _count ) {
+% 	if( context_will_exit( _monitors, count ) ) {
+% 		baton_pass();
+% 		return;
+% 	}
+
+% 	for( mon in _monitors ) {
+% 		release( mon );
+% 	}
+% }
+
+% \end{lstlisting}
+
+
+
+% A direct extension of the single monitor semantics is to release all locks when waiting and transferring ownership of all locks when signalling. However, for the purpose of synchronization it may be usefull to only release some of the locks but keep others. It is possible to support internal scheduling and \gls{group-acquire} without any extra syntax by relying on order of acquisition. Here is an example of the different contexts in which internal scheduling can be used. (Note that here the use of helper routines is irrelevant, only routines acquire mutual exclusion have an impact on internal scheduling):
+
+% \begin{table}[h!]
+% \centering
+% \begin{tabular}{|c|c|c|}
+% Context 1 & Context 2 & Context 3 \\
+% \hline
+% \begin{lstlisting}
+% condition e;
+
+% //acquire a & b
+% void foo(monitor & mutex a,
+%            monitor & mutex b) {
+
+% 	wait(e); //release a & b
+% }
+
+
+
+
+
+
+% foo(a,b);
+% \end{lstlisting} &\begin{lstlisting}
+% condition e;
+
+% //acquire a
+% void bar(monitor & mutex a,
+%            monitor & nomutex b) {
+% 	foo(a,b);
+% }
+
+% //acquire a & b
+% void foo(monitor & mutex a,
+%            monitor & mutex b) {
+% 	wait(e);  //release a & b
+% }
+
+% bar(a, b);
+% \end{lstlisting} &\begin{lstlisting}
+% condition e;
+
+% //acquire a
+% void bar(monitor & mutex a,
+%            monitor & nomutex b) {
+% 	baz(a,b);
+% }
+
+% //acquire b
+% void baz(monitor & nomutex a,
+%            monitor & mutex b) {
+% 	wait(e);  //release b
+% }
+
+% bar(a, b);
+% \end{lstlisting}
+% \end{tabular}
+% \end{table}
+
+% Context 1 is the simplest way of acquiring more than one monitor (\gls{group-acquire}), using a routine with multiple parameters having the \code{mutex} keyword. Context 2 also uses \gls{group-acquire} as well in routine \code{foo}. However, the routine is called by routine \code{bar}, which only acquires monitor \code{a}. Since monitors can be acquired multiple times this does not cause a deadlock by itself but it does force the acquiring order to \code{a} then \code{b}. Context 3 also forces the acquiring order to be \code{a} then \code{b} but does not use \gls{group-acquire}. The previous example tries to illustrate the semantics that must be established to support releasing monitors in a \code{wait} statement. In all cases, the behavior of the wait statment is to release all the locks that were acquired my the inner-most monitor call. That is \code{a & b} in context 1 and 2 and \code{b} only in context 3. Here are a few other examples of this behavior.
+
+
+% \begin{center}
+% \begin{tabular}{|c|c|c|}
+% \begin{lstlisting}
+% condition e;
+
+% //acquire b
+% void foo(monitor & nomutex a,
+%            monitor & mutex b) {
+% 	bar(a,b);
+% }
+
+% //acquire a
+% void bar(monitor & mutex a,
+%            monitor & nomutex b) {
+
+% 	wait(e); //release a
+% 	          //keep b
+% }
+
+% foo(a, b);
+% \end{lstlisting} &\begin{lstlisting}
+% condition e;
+
+% //acquire a & b
+% void foo(monitor & mutex a,
+%            monitor & mutex b) {
+% 	bar(a,b);
+% }
+
+% //acquire b
+% void bar(monitor & mutex a,
+%            monitor & nomutex b) {
+
+% 	wait(e); //release b
+% 	          //keep a
+% }
+
+% foo(a, b);
+% \end{lstlisting} &\begin{lstlisting}
+% condition e;
+
+% //acquire a & b
+% void foo(monitor & mutex a,
+%            monitor & mutex b) {
+% 	bar(a,b);
+% }
+
+% //acquire none
+% void bar(monitor & nomutex a,
+%            monitor & nomutex b) {
+
+% 	wait(e); //release a & b
+% 	          //keep none
+% }
+
+% foo(a, b);
+% \end{lstlisting}
+% \end{tabular}
+% \end{center}
+% Note the right-most example is actually a trick pulled on the reader. Monitor state information is stored in thread local storage rather then in the routine context, which means that helper routines and other \code{nomutex} routines are invisible to the runtime system in regards to concurrency. This means that in the right-most example, the routine parameters are completly unnecessary. However, calling this routine from outside a valid monitor context is undefined.
+
+% These semantics imply that in order to release of subset of the monitors currently held, users must write (and name) a routine that only acquires the desired subset and simply calls wait. While users can use this method, \CFA offers the \code{wait_release}\footnote{Not sure if an overload of \code{wait} would work...} which will release only the specified monitors. In the center previous examples, the code in the center uses the \code{bar} routine to only release monitor \code{b}. Using the \code{wait_release} helper, this can be rewritten without having the name two routines :
+% \begin{center}
+% \begin{tabular}{ c c c }
+% \begin{lstlisting}
+% 	condition e;
+
+% 	//acquire a & b
+% 	void foo(monitor & mutex a,
+% 	           monitor & mutex b) {
+% 		bar(a,b);
+% 	}
+
+% 	//acquire b
+% 	void bar(monitor & mutex a,
+% 	           monitor & nomutex b) {
+
+% 		wait(e); //release b
+% 		          //keep a
+% 	}
+
+% 	foo(a, b);
+% \end{lstlisting} &\begin{lstlisting}
+% 	=>
+% \end{lstlisting} &\begin{lstlisting}
+% 	condition e;
+
+% 	//acquire a & b
+% 	void foo(monitor & mutex a,
+% 	           monitor & mutex b) {
+% 		wait_release(e,b); //release b
+% 			                 //keep a
+% 	}
+
+% 	foo(a, b);
+% \end{lstlisting}
+% \end{tabular}
+% \end{center}
+
+% Regardless of the context in which the \code{wait} statement is used, \code{signal} must be called holding the same set of monitors. In all cases, signal only needs a single parameter, the condition variable that needs to be signalled. But \code{signal} needs to be called from the same monitor(s) that call to \code{wait}. Otherwise, mutual exclusion cannot be properly transferred back to the waiting monitor.
+
+% Finally, an additional semantic which can be very usefull is the \code{signal_block} routine. This routine behaves like signal for all of the semantics discussed above, but with the subtelty that mutual exclusion is transferred to the waiting task immediately rather than wating for the end of the critical section.
+% \\
+
+% ####### #     # #######         #####   #####  #     # ####### ######
+% #        #   #     #           #     # #     # #     # #       #     #
+% #         # #      #           #       #       #     # #       #     #
+% #####      #       #            #####  #       ####### #####   #     #
+% #         # #      #    ###          # #       #     # #       #     #
+% #        #   #     #    ###    #     # #     # #     # #       #     #
+% ####### #     #    #    ###     #####   #####  #     # ####### ######
+\section{External scheduling} \label{extsched}
+An alternative to internal scheduling is to use external scheduling instead. This method is more constrained and explicit which may help users tone down the undeterministic nature of concurrency. Indeed, as the following examples demonstrates, external scheduling allows users to wait for events from other threads without the concern of unrelated events occuring. External scheduling can generally be done either in terms of control flow (ex: \uC) or in terms of data (ex: Go). Of course, both of these paradigms have their own strenghts and weaknesses but for this project control flow semantics where chosen to stay consistent with the rest of the languages semantics. Two challenges specific to \CFA arise when trying to add external scheduling with loose object definitions and multi-monitor routines. The following example shows a simple use \code{accept} versus \code{wait}/\code{signal} and its advantages.
+
+\begin{center}
+\begin{tabular}{|c|c|}
+Internal Scheduling & External Scheduling \\
+\hline
+\begin{lstlisting}
+	_Monitor blarg {
+		condition c;
+	public:
+		void f() { signal(c)}
+		void g() { wait(c); }
+	private:
+	}
+\end{lstlisting}&\begin{lstlisting}
+	_Monitor blarg {
+
+	public:
+		void f() { /*...*/ }
+		void g() { _Accept(f); }
+	private:
+	}
+\end{lstlisting}
+\end{tabular}
+\end{center}
+
+In the case of internal scheduling, the call to \code{wait} only guarantees that \code{g} is the last routine to access the monitor. This intails that the routine \code{f} may have acquired mutual exclusion several times while routine \code{h} was waiting. On the other hand, external scheduling guarantees that while routine \code{h} was waiting, no routine other than \code{g} could acquire the monitor.
+\\
+
+% #       ####### #######  #####  #######    ####### ######        #  #####
+% #       #     # #     # #     # #          #     # #     #       # #     #
+% #       #     # #     # #       #          #     # #     #       # #
+% #       #     # #     #  #####  #####      #     # ######        #  #####
+% #       #     # #     #       # #          #     # #     # #     #       #
+% #       #     # #     # #     # #          #     # #     # #     # #     #
+% ####### ####### #######  #####  #######    ####### ######   #####   #####
+
+\subsection{Loose object definitions}
+In \uC, monitor declarations include an exhaustive list of monitor operations. Since \CFA is not object oriented it becomes both more difficult to implement but also less clear for the user :
+
+\begin{lstlisting}
+	mutex struct A {};
+
+	void f(A & mutex a);
+	void g(A & mutex a) { accept(f); }
+\end{lstlisting}
+
+However, external scheduling is an example where implementation constraints become visible from the interface. Indeed, ince there is no hard limit to the number of threads trying to acquire a monitor concurrently, performance is a significant concern. Here is the pseudo code for the entering phase of a monitor :
+
+\begin{center}
+\begin{tabular}{l}
+\begin{lstlisting}[language=Pseudo]
+	if monitor is free :
+		enter
+	elif monitor accepts me :
+		enter
+	else :
+		block
+\end{lstlisting}
+\end{tabular}
+\end{center}
+
+For the \pscode{monitor is free} condition it is easy to implement a check that can evaluate the condition in a few instruction. However, a fast check for \pscode{monitor accepts me} is much harder to implement depending on the constraints put on the monitors. Indeed, monitors are often expressed as an entry queue and some acceptor queue as in the following figure :
+
+\begin{center}
+{\resizebox{0.4\textwidth}{!}{\input{monitor}}}
+\end{center}
+
+There are other alternatives to these pictures but in the case of this picture implementing a fast accept check is relatively easy. Indeed simply updating a bitmask when the acceptor queue changes is enough to have a check that executes in a single instruction, even with a fairly large number of acceptor. However, this relies on the fact that all the acceptable routines are declared with the monitor type. For OO languages this doesn't compromise much since monitors already have an exhaustive list of member routines. However, for \CFA this isn't the case, routines can be added to a type anywhere after its declaration. Its important to note that the bitmask approach does not actually require an exhaustive list of routines, but it requires a dense unique ordering of routines with an upper-bound and that ordering must be consistent across translation units.
+The alternative would be to have a picture more like this one:
+
+\begin{center}
+{\resizebox{0.4\textwidth}{!}{\input{ext_monitor}}}
+\end{center}
+
+Not storing the queues inside the monitor means that the storage can vary between routines, allowing for more flexibility and extensions. Storing an array of function-pointers would solve the issue of uniquely identifying acceptable routines. However, the single instruction bitmask compare has been replaced by dereferencing a pointer followed by a linear search. Furthermore, supporting nested external scheduling may now require additionnal searches on calls to accept to check if a routine is already queued in.
+
+At this point we must make a decision between flexibility and performance. Many design decisions in \CFA achieve both flexibility and performance, for example polymorphic routines add significant flexibility but inlining them means the optimizer can easily remove any runtime cost. Here however, the cost of flexibility cannot be trivially removed.
+
+In either cases here are a few alternatives for the different syntaxes this syntax : \\
+\begin{center}
+{\renewcommand{\arraystretch}{1.5}
+\begin{tabular}[t]{l @{\hskip 0.35in} l}
+\hline
+\multicolumn{2}{ c }{\code{accept} on type}\\
+\hline
+Alternative 1 & Alternative 2 \\
+\begin{lstlisting}
+mutex struct A
+accept( void f(A & mutex a) )
+{};
+\end{lstlisting} &\begin{lstlisting}
+mutex struct A {}
+accept( void f(A & mutex a) );
+
+\end{lstlisting} \\
+Alternative 3 & Alternative 4 \\
+\begin{lstlisting}
+mutex struct A {
+	accept( void f(A & mutex a) )
+};
+
+\end{lstlisting} &\begin{lstlisting}
+mutex struct A {
+	accept :
+		void f(A & mutex a) );
+};
+\end{lstlisting}\\
+\hline
+\multicolumn{2}{ c }{\code{accept} on routine}\\
+\hline
+\begin{lstlisting}
+mutex struct A {};
+
+void f(A & mutex a)
+
+accept( void f(A & mutex a) )
+void g(A & mutex a) {
+	/*...*/
+}
+\end{lstlisting}&\\
+\end{tabular}
+}
+\end{center}
+
+An other aspect to consider is what happens if multiple overloads of the same routine are used. For the time being it is assumed that multiple overloads of the same routine should be scheduled regardless of the overload used. However, this could easily be extended in the future.
+
+% #     # #     # #       ####### ###    #     # ####### #     #
+% ##   ## #     # #          #     #     ##   ## #     # ##    #
+% # # # # #     # #          #     #     # # # # #     # # #   #
+% #  #  # #     # #          #     #     #  #  # #     # #  #  #
+% #     # #     # #          #     #     #     # #     # #   # #
+% #     # #     # #          #     #     #     # #     # #    ##
+% #     #  #####  #######    #    ###    #     # ####### #     #
+
+\subsection{Multi-monitor scheduling}
+
+External scheduling, like internal scheduling, becomes orders of magnitude more complex when we start introducing multi-monitor syntax. Even in the simplest possible case some new semantics need to be established :
+\begin{lstlisting}
+	accept( void f(mutex struct A & mutex this))
+	mutex struct A {};
+
+	mutex struct B {};
+
+	void g(A & mutex a, B & mutex b) {
+		accept(f); //ambiguous, which monitor
+	}
+\end{lstlisting}
+
+The obvious solution is to specify the correct monitor as follows :
+
+\begin{lstlisting}
+	accept( void f(mutex struct A & mutex this))
+	mutex struct A {};
+
+	mutex struct B {};
+
+	void g(A & mutex a, B & mutex b) {
+		accept( f, b );
+	}
+\end{lstlisting}
+
+This is unambiguous. Both locks will be acquired and kept, when routine \code{f} is called the lock for monitor \code{a} will be temporarily transferred from \code{g} to \code{f} (while \code{g} still holds lock \code{b}). This behavior can be extended to multi-monitor accept statment as follows.
+
+\begin{lstlisting}
+	accept( void f(mutex struct A & mutex, mutex struct A & mutex))
+	mutex struct A {};
+
+	mutex struct B {};
+
+	void g(A & mutex a, B & mutex b) {
+		accept( f, b, a );
+	}
+\end{lstlisting}
+
+Note that the set of monitors passed to the \code{accept} statement must be entirely contained in the set of monitor already acquired in the routine. \code{accept} used in any other context is Undefined Behaviour.
+
+% ######  ####### #######    #    ### #        #####
+% #     # #          #      # #    #  #       #     #
+% #     # #          #     #   #   #  #       #
+% #     # #####      #    #     #  #  #        #####
+% #     # #          #    #######  #  #             #
+% #     # #          #    #     #  #  #       #     #
+% ######  #######    #    #     # ### #######  #####
+%
+% 		 #####  #     # ####### #     # #######  #####
+% 	      #     # #     # #       #     # #       #     #
+% 	      #     # #     # #       #     # #       #
+%    #####    #     # #     # #####   #     # #####    #####
+% 	      #   # # #     # #       #     # #             #
+% 	      #    #  #     # #       #     # #       #     #
+% 		 #### #  #####  #######  #####  #######  #####
+
+
+\subsection{Implementation Details: External scheduling queues}
+To support multi-monitor external scheduling means that some kind of entry-queues must be used that is aware of both monitors. However, acceptable routines must be aware of the entry queues which means they must be stored inside at least one of the monitors that will be acquired. This in turn adds the requirement a systematic algorithm of disambiguating which queue is relavant regardless of user ordering. The proposed algorithm is to fall back on monitors lock ordering and specify that the monitor that is acquired first is the lock with the relevant entry queue. This assumes that the lock acquiring order is static for the lifetime of all concerned objects but that is a reasonnable constraint. This algorithm choice has two consequences, the entry queue of the highest priority monitor is no longer a true FIFO queue and the queue of the lowest priority monitor is both required and probably unused. The queue can no longer be a FIFO queue because instead of simply containing the waiting threads in order arrival, they also contain the second mutex. Therefore, another thread with the same highest priority monitor but a different lowest priority monitor may arrive first but enter the critical section after a thread with the correct pairing. Secondly, since it may not be known at compile time which monitor will be the lowest priority monitor, every monitor needs to have the correct queues even though it is probable that half the multi-monitor queues will go unused for the entire duration of the program.
+
+\section{Other concurrency tools}
+TO BE CONTINUED...
+
+
+
+
+
+
+
+
+
+
+% ######     #    ######     #    #       #       ####### #       ###  #####  #     #
+% #     #   # #   #     #   # #   #       #       #       #        #  #     # ##   ##
+% #     #  #   #  #     #  #   #  #       #       #       #        #  #       # # # #
+% ######  #     # ######  #     # #       #       #####   #        #   #####  #  #  #
+% #       ####### #   #   ####### #       #       #       #        #        # #     #
+% #       #     # #    #  #     # #       #       #       #        #  #     # #     #
+% #       #     # #     # #     # ####### ####### ####### ####### ###  #####  #     #
+\chapter{Parallelism}
+Historically, computer performance was about processor speeds and instructions count. However, with heat dissipation being a direct consequence of speed increase, parallelism has become the new source for increased performance~\cite{Sutter05, Sutter05b}. In this decade, it is not longer reasonnable to create a high-performance application without caring about parallelism. Indeed, parallelism is an important aspect of performance and more specifically throughput and hardware utilization. The lowest-level approach of parallelism is to use \glspl{kthread} in combination with semantics like \code{fork}, \code{join}, etc. However, since these have significant costs and limitations, \glspl{kthread} are now mostly used as an implementation tool rather than a user oriented one. There are several alternatives to solve these issues that all have strengths and weaknesses. While there are many variations of the presented paradigms, most of these variations do not actually change the guarantees or the semantics, they simply move costs in order to achieve better performance for certain workloads.
+
+\section{Paradigm}
+\subsection{User-level threads}
+A direct improvement on the \gls{kthread} approach is to use \glspl{uthread}. These threads offer most of the same features that the operating system already provide but can be used on a much larger scale. This approach is the most powerfull solution as it allows all the features of multi-threading, while removing several of the more expensives costs of using kernel threads. The down side is that almost none of the low-level threading problems are hidden, users still have to think about data races, deadlocks and synchronization issues. These issues can be somewhat alleviated by a concurrency toolkit with strong garantees but the parallelism toolkit offers very little to reduce complexity in itself.
+
+Examples of languages that support \glspl{uthread} are Erlang~\cite{Erlang} and \uC~\cite{uC++book}.
+
+\subsection{Fibers : user-level threads without preemption}
+A popular varient of \glspl{uthread} is what is often reffered to as \glspl{fiber}. However, \glspl{fiber} do not present meaningful semantical differences with \glspl{uthread}. Advocates of \glspl{fiber} list their high performance and ease of implementation as majors strenghts of \glspl{fiber} but the performance difference between \glspl{uthread} and \glspl{fiber} is controversial and the ease of implementation, while true, is a weak argument in the context of language design. Therefore this proposal largely ignore fibers.
+
+An example of a language that uses fibers is Go~\cite{Go}
+
+\subsection{Jobs and thread pools}
+The approach on the opposite end of the spectrum is to base parallelism on \glspl{pool}. Indeed, \glspl{pool} offer limited flexibility but at the benefit of a simpler user interface. In \gls{pool} based systems, users express parallelism as units of work and a dependency graph (either explicit or implicit) that tie them together. This approach means users need not worry about concurrency but significantly limits the interaction that can occur among jobs. Indeed, any \gls{job} that blocks also blocks the underlying worker, which effectively means the CPU utilization, and therefore throughput, suffers noticeably. It can be argued that a solution to this problem is to use more workers than available cores. However, unless the number of jobs and the number of workers are comparable, having a significant amount of blocked jobs always results in idles cores.
+
+The gold standard of this implementation is Intel's TBB library~\cite{TBB}.
+
+\subsection{Paradigm performance}
+While the choice between the three paradigms listed above may have significant performance implication, it is difficult to pindown the performance implications of chosing a model at the language level. Indeed, in many situations one of these paradigms may show better performance but it all strongly depends on the workload. Having a large amount of mostly independent units of work to execute almost guarantess that the \gls{pool} based system has the best performance thanks to the lower memory overhead. However, interactions between jobs can easily exacerbate contention. User-level threads allow fine-grain context switching, which results in better resource utilisation, but context switches will be more expansive and the extra control means users need to tweak more variables to get the desired performance. Furthermore, if the units of uninterrupted work are large enough the paradigm choice is largely amorticised by the actual work done.
+
+%  #####  #######    #          ####### ######  ######
+% #     # #         # #            #    #     # #     #
+% #       #        #   #           #    #     # #     #
+% #       #####   #     # #####    #    ######  ######
+% #       #       #######          #    #     # #     #
+% #     # #       #     #          #    #     # #     #
+%  #####  #       #     #          #    ######  ######
+
+\section{\CFA 's Thread Building Blocks}
+As a system-level language, \CFA should offer both performance and flexibilty as its primary goals, simplicity and user-friendliness being a secondary concern. Therefore, the core of parallelism in \CFA should prioritize power and efficiency. With this said, deconstructing popular paradigms in order to get simple building blocks yields \glspl{uthread} as the core parallelism block. \Glspl{pool} and other parallelism paradigms can then be built on top of the underlying threading model.
+
+\subsection{Coroutines : A stepping stone}\label{coroutine}
+While the main focus of this proposal is concurrency and paralellism, it is important to adress coroutines which are actually a significant underlying aspect of the concurrency system. Indeed, while having nothing todo with parallelism and arguably very little to do with concurrency, coroutines need to deal with context-switchs and and other context management operations. Therefore, this proposal includes coroutines both as an intermediate step for the implementation of threads and a first class feature of \CFA.
+
+The core API of coroutines revolve around two features : independent stacks and \code{suspend}/\code{resume}.
+Here is an example of a solution to the fibonnaci problem using \CFA coroutines :
+\begin{lstlisting}
+	struct Fibonacci {
+	      int fn; // used for communication
+	      coroutine_descriptor c;
+	};
+
+	void ?{}(Fibonacci* this) {
+	      this->fn = 0;
+	}
+
+	coroutine_descriptor* get_¶coroutine¶(Fibonacci* this) {
+	      return &this->c;
+	}
+
+	void co_main(Fibonacci* this) {
+		int fn1, fn2; 		// retained between resumes
+		this->fn = 0;
+		fn1 = this->fn;
+		suspend(this); 		// return to last resume
+
+		this->fn = 1;
+		fn2 = fn1;
+		fn1 = this->fn;
+		suspend(this); 		// return to last resume
+
+		for ( ;; ) {
+			this->fn = fn1 + fn2;
+			fn2 = fn1;
+			fn1 = this->fn;
+			suspend(this); 	// return to last resume
+		}
+	}
+
+	int next(Fibonacci* this) {
+		resume(this); // transfer to last suspend
+		return this.fn;
+	}
+
+	void main() {
+		Fibonacci f1, f2;
+		for ( int i = 1; i <= 10; i += 1 ) {
+			sout | next(&f1) | '§\verb+ +§' | next(&f2) | endl;
+		}
+	}
+\end{lstlisting}
+
+\subsubsection{Construction}
+One important design challenge for coroutines and threads (shown in section \ref{threads}) is that the runtime system needs to run some code after the user-constructor runs. In the case of the coroutines this challenge is simpler since there is no loss of determinism brough by preemption or scheduling, however, the underlying challenge remains the same for coroutines and threads.
+
+The runtime system needs to create the coroutine's stack and more importantly prepare it for the first resumption. The timing of the creation is non trivial since users both expect to have fully constructed objects once the main is called and to be able to resume the coroutine from the main (Obviously we only solve cases where these two statements don't conflict). There are several solutions to this problem but the chosen options effectively forces the design of the coroutine.
+
+Furthermore, \CFA faces an extra challenge which is that polymorphique routines rely on invisible thunks when casted to non-polymorphic routines and these thunks have function scope, for example :
+
+TODO : Simple case where a thunk would be created.
+
+
+
+\subsubsection{Alternative: Inheritance}
+One solution to this challenge would be to use inheritence,
+
+\begin{lstlisting}
+	struct Fibonacci {
+	      int fn; // used for communication
+	      coroutine c;
+	};
+
+	void ?{}(Fibonacci* this) {
+	      this->fn = 0;
+		(&this->c){};
+	}
+\end{lstlisting}
+
+There are two downsides to the approach. The first, which is relatively minor, is that the base class needs to be made aware of the main routine pointer, regardless of whether we use a parameter or a virtual pointer, this means the coroutine data must be made larger to store a value that is actually a compile time constant (The address of the main routine). The second problem which is both subtle but significant, is that now can get the initialisation order of there coroutines wrong. Indeed, every field of a \CFA struct will be constructed but in the order of declaration, unless users explicitly write otherwise. This means that users who forget to initialize a the coroutine at the right time may resume the coroutine at with an uninitilized object. For coroutines, this is unlikely to be a problem, for threads however, this is a significant problem.
+
+\subsubsection{Alternative: Reserved keyword}
+The next alternative is to use language support to annotate coroutines as follows :
+
+\begin{lstlisting}
+	coroutine struct Fibonacci {
+	      int fn; // used for communication
+	};
+\end{lstlisting}
+
+This mean the compiler can solve problems by injecting code where needed. The downside of this approach is that it makes coroutine a special case in the language. Users who would want to extend coroutines or build their own for various reasons can only do so in ways offered by the language. Furthermore, implementing coroutines without language supports also displays the power of \CFA.
+
+\subsubsection{Alternative: Lamda Objects}
+
+Boost does not use objects...
+TO BE CONTINUED...
+
+\subsubsection{Trait based coroutines}
+
+Finally the approach chosen, which is the one closest to \CFA idioms, is to use trait-based lazy coroutines, the approach shown in section \ref{coroutine}. This approach defines a coroutine as anything that satisfies the \code{is_coroutine} and is used as a coroutine is a coroutine. This entails the an object is not a coroutine until \code{resume} (and \code{prime}) is called on the object. Correspondingly, any object that is passed to \code{resume} is a coroutine since it must satisfy the \code{is_coroutine} trait to compile.
+
+% ####### #     # ######  #######    #    ######   #####
+%    #    #     # #     # #         # #   #     # #     #
+%    #    #     # #     # #        #   #  #     # #
+%    #    ####### ######  #####   #     # #     #  #####
+%    #    #     # #   #   #       ####### #     #       #
+%    #    #     # #    #  #       #     # #     # #     #
+%    #    #     # #     # ####### #     # ######   #####
+
+\subsection{Thread Interface}\label{threads}
+The basic building blocks of \CFA are \glspl{cfathread}. By default these are implemented as \glspl{uthread}, and as such, offer a flexible and lightweight threading interface (lightweight compared to \glspl{kthread}). A thread can be declared using a struct declaration with prefix \code{thread} as follows :
+
+\begin{lstlisting}
+	trait is_¶thread¶(dtype T) {
+		void co_main(T* this);
+		coroutine* get_coroutine(T* this);
+	};
+
+	thread struct foo {};
+\end{lstlisting}
+
+Obviously, for this thread implementation to be usefull it must run some user code. Several other threading interfaces use a function-pointer representation as the interface of threads (for example : \Csharp~\cite{Csharp} and Scala~\cite{Scala}). However, this proposal considers that statically tying a \code{main} routine to a thread superseeds this approach. Since the \code{main} routine is already a special routine in \CFA (where the program begins), the existing syntax for declaring routines names with special semantics can be extended, i.e. operator overloading. As such the \code{main} routine of a thread can be defined as :
+\begin{lstlisting}
+	thread struct foo {};
+
+	void ?main(foo* this) {
+		sout | "Hello World!" | endl;
+	}
+\end{lstlisting}
+
+In this example, threads of type \code{foo} will start there execution in the \code{void ?main(foo*)} routine which in this case prints \code{"Hello World!"}. While this proposoal encourages this approach which is enforces strongly type programming. Users may prefer to use the routine based thread semantics for the sake of simplicity. With these semantics it is trivial to write a thread type that takes a function pointer as parameter and executes it on its stack asynchronously :
+\begin{lstlisting}
+	typedef void (*voidFunc)(void);
+
+	thread struct FuncRunner {
+		voidFunc func;
+	};
+
+	//ctor
+	void ?{}(FuncRunner* this, voidFunc inFunc) {
+		func = inFunc;
+	}
+
+	//main
+	void t_main(FuncRunner* this) {
+		this->func();
+	}
+\end{lstlisting}
+
+Of course for threads to be useful, it must be possible to start and stop threads and wait for them to complete execution. While using an \acrshort{api} such as \code{fork} and \code{join} is relatively common in the literature, such an interface is unnecessary. Indeed, the simplest approach is to use \acrshort{raii} principles and have threads \code{fork} once the constructor has completed and \code{join} before the destructor runs.
+\begin{lstlisting}
+thread struct World; //FuncRunner declared above
+
+void ?main(thread World* this) {
+	sout | "World!" | endl;
+}
+
+void main() {
+	World w;
+	//Thread run forks here
+
+	//Print to "Hello " and "World!" will be run concurrently
+	sout | "Hello " | endl;
+
+	//Implicit join at end of scope
+}
+\end{lstlisting}
+This semantic has several advantages over explicit semantics : typesafety is guaranteed, a thread is always started and stopped exaclty once and users cannot make any progamming errors. However, one of the apparent drawbacks of this system is that threads now always form a lattice, that is they are always destroyed in opposite order of construction. While this seems like a significant limitation, existing \CFA semantics can solve this problem. Indeed, by using dynamic allocation to create threads will naturally let threads outlive the scope in which the thread was created much like dynamically allocating memory will let objects outlive the scope in which thy were created :
+
+\begin{lstlisting}
+	thread struct MyThread {
+		//...
+	};
+
+	//ctor
+	void ?{}(MyThread* this,
+		     bool is_special = false) {
+		//...
+	}
+
+	//main
+	void ?main(MyThread* this) {
+		//...
+	}
+
+	void foo() {
+		MyThread* special_thread;
+		{
+			MyThread thrds = {false};
+			//Start a thread at the beginning of the scope
+
+			DoStuff();
+
+			//create a other thread that will outlive the thread in this scope
+			special_thread = new MyThread{true};
+
+			//Wait for the thread to finish
+		}
+		DoMoreStuff();
+
+		//Now wait for the special
+	}
+\end{lstlisting}
+
+Another advantage of this semantic is that it naturally scale to multiple threads meaning basic synchronisation is very simple :
+
+\begin{lstlisting}
+	thread struct MyThread {
+		//...
+	};
+
+	//ctor
+	void ?{}(MyThread* this) {}
+
+	//main
+	void ?main(MyThread* this) {
+		//...
+	}
+
+	void foo() {
+		MyThread thrds[10];
+		//Start 10 threads at the beginning of the scope
+
+		DoStuff();
+
+		//Wait for the 10 threads to finish
+	}
+\end{lstlisting}
+
+\newpage
+\bf{WORK IN PROGRESS}
+\subsection{The \CFA Kernel : Processors, Clusters and Threads}\label{kernel}
+
+
+\subsection{Paradigms}\label{cfaparadigms}
+Given these building blocks we can then reproduce the all three of the popular paradigms. Indeed, we get \glspl{uthread} as the default paradigm in \CFA. However, disabling \glspl{preemption} on the \gls{cfacluster} means \glspl{cfathread} effectively become \glspl{fiber}. Since several \glspl{cfacluster} with different scheduling policy can coexist in the same application, this allows \glspl{fiber} and \glspl{uthread} to coexist in the runtime of an application.
+
+% \subsection{High-level options}\label{tasks}
+%
+% \subsubsection{Thread interface}
+% constructors destructors
+% 	initializer lists
+% monitors
+%
+% \subsubsection{Futures}
+%
+% \subsubsection{Implicit threading}
+% Finally, simpler applications can benefit greatly from having implicit parallelism. That is, parallelism that does not rely on the user to write concurrency. This type of parallelism can be achieved both at the language level and at the system level.
+%
+% \begin{center}
+% \begin{tabular}[t]{|c|c|c|}
+% Sequential & System Parallel & Language Parallel \\
+% \begin{lstlisting}
+% void big_sum(int* a, int* b,
+% 		 int* out,
+% 		 size_t length)
+% {
+% 	for(int i = 0; i < length; ++i ) {
+% 		out[i] = a[i] + b[i];
+% 	}
+% }
+%
+%
+%
+%
+%
+% int* a[10000];
+% int* b[10000];
+% int* c[10000];
+% //... fill in a and b ...
+% big_sum(a, b, c, 10000);
+% \end{lstlisting} &\begin{lstlisting}
+% void big_sum(int* a, int* b,
+% 		 int* out,
+% 		 size_t length)
+% {
+% 	range ar(a, a + length);
+% 	range br(b, b + length);
+% 	range or(out, out + length);
+% 	parfor( ai, bi, oi,
+% 	[](int* ai, int* bi, int* oi) {
+% 		oi = ai + bi;
+% 	});
+% }
+%
+% int* a[10000];
+% int* b[10000];
+% int* c[10000];
+% //... fill in a and b ...
+% big_sum(a, b, c, 10000);
+% \end{lstlisting}&\begin{lstlisting}
+% void big_sum(int* a, int* b,
+% 		 int* out,
+% 		 size_t length)
+% {
+% 	for (ai, bi, oi) in (a, b, out) {
+% 		oi = ai + bi;
+% 	}
+% }
+%
+%
+%
+%
+%
+% int* a[10000];
+% int* b[10000];
+% int* c[10000];
+% //... fill in a and b ...
+% big_sum(a, b, c, 10000);
+% \end{lstlisting}
+% \end{tabular}
+% \end{center}
+%
+% \subsection{Machine setup}\label{machine}
+% Threads are all good and well but wee still some OS support to fully utilize available hardware.
+%
+% \textbf{\large{Work in progress...}} Do wee need something beyond specifying the number of kernel threads?
+
+%    #    #       #
+%   # #   #       #
+%  #   #  #       #
+% #     # #       #
+% ####### #       #
+% #     # #       #
+% #     # ####### #######
+\chapter{Putting it all together}
+
+
+
+
+
+\chapter{Conclusion}
+
+
+
+
+
+
+% ####### #     # ####### #     # ######  #######
+% #       #     #    #    #     # #     # #
+% #       #     #    #    #     # #     # #
+% #####   #     #    #    #     # ######  #####
+% #       #     #    #    #     # #   #   #
+% #       #     #    #    #     # #    #  #
+% #        #####     #     #####  #     # ######
+\chapter{Future work}
+Concurrency and parallelism is still a very active field that strongly benefits from hardware advances. As such certain features that aren't necessarily mature enough in their current state could become relevant in the lifetime of \CFA.
+\subsection{Transactions}
+
+% ####### #     # ######
+% #       ##    # #     #
+% #       # #   # #     #
+% #####   #  #  # #     #
+% #       #   # # #     #
+% #       #    ## #     #
+% ####### #     # ######
+\section*{Acknowledgements}
+
+\clearpage
+\printglossary[type=\acronymtype]
+\printglossary
+
+\clearpage
+\bibliographystyle{plain}
+\bibliography{cw92,distSharedMem,lfp92,mlw92,parallel,parallelIO,partheory,pl,pldi92,ps,realtime,techreportsPAB,visual,local}
+
+
+\end{document}
Index: doc/proposals/concurrency/cor-thread-traits.c
===================================================================
--- doc/proposals/concurrency/cor-thread-traits.c	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
+++ doc/proposals/concurrency/cor-thread-traits.c	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
@@ -0,0 +1,90 @@
+//-----------------------------------------------------------------------------
+// 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/proposals/concurrency/ext_monitor.fig
===================================================================
--- doc/proposals/concurrency/ext_monitor.fig	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
+++ doc/proposals/concurrency/ext_monitor.fig	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
@@ -0,0 +1,94 @@
+#FIG 3.2  Produced by xfig version 3.2.5c
+Landscape
+Center
+Inches
+Letter  
+100.00
+Single
+-2
+1200 2
+5 1 0 1 -1 -1 0 0 -1 0.000 0 1 0 0 3150.000 3450.000 3150 3150 2850 3450 3150 3750
+5 1 0 1 -1 -1 0 0 -1 0.000 0 1 0 0 3150.000 4350.000 3150 4050 2850 4350 3150 4650
+6 5850 1950 6150 2250
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6000 2100 105 105 6000 2100 6105 2205
+4 1 -1 0 0 0 10 0.0000 2 105 90 6000 2160 d\001
+-6
+6 5850 1650 6150 1950
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6000 1800 105 105 6000 1800 6105 1905
+4 1 -1 0 0 0 10 0.0000 2 105 90 6000 1860 b\001
+-6
+6 5100 1800 5400 2100
+1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 5250 1950 105 105 5250 1950 5355 1950
+4 1 -1 0 0 0 10 0.0000 2 105 120 5250 2010 Y\001
+-6
+6 5100 2100 5400 2400
+1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 5250 2250 105 105 5250 2250 5355 2250
+4 1 -1 0 0 0 10 0.0000 2 105 120 5250 2295 X\001
+-6
+6 3000 5400 7200 5700
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 3150 5550 80 80 3150 5550 3230 5630
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4500 5550 105 105 4500 5550 4605 5655
+1 3 0 1 -1 -1 0 0 4 0.000 1 0.0000 6000 5550 105 105 6000 5550 6105 5655
+4 0 -1 0 0 0 12 0.0000 2 135 1035 4725 5625 blocked task\001
+4 0 -1 0 0 0 12 0.0000 2 135 870 3300 5625 active task\001
+4 0 -1 0 0 0 12 0.0000 2 180 930 6225 5625 routine ptrs\001
+-6
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3300 3600 105 105 3300 3600 3405 3705
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3600 3600 105 105 3600 3600 3705 3705
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6600 3900 105 105 6600 3900 6705 4005
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6900 3900 105 105 6900 3900 7005 4005
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6000 2700 105 105 6000 2700 6105 2805
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6000 2400 105 105 6000 2400 6105 2505
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 5100 4575 80 80 5100 4575 5180 4655
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+	 4050 2925 5475 2925 5475 3225 4050 3225 4050 2925
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+	 5850 2850 6075 3000
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4
+	 3150 3750 3750 3750 3750 4050 3150 4050
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3
+	 3150 3450 3750 3450 3900 3675
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+	 3750 3150 3600 3375
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3
+	 3150 4350 3750 4350 3900 4575
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+	 3750 4050 3600 4275
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4
+	 3150 4650 3750 4650 3750 4950 4950 4950
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+	 6450 3750 6300 3975
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+	 4950 4950 5175 5100
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 9
+	 5250 4950 6450 4950 6450 4050 7050 4050 7050 3750 6450 3750
+	 6450 2850 6150 2850 6150 1650
+2 2 1 1 -1 -1 0 0 -1 4.000 0 0 0 0 0 5
+	 5850 4200 5850 3300 4350 3300 4350 4200 5850 4200
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3
+	 5250 2850 5850 2850 5850 1650
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4
+	 3150 3150 3750 3150 3750 2850 5325 2850
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
+	1 1 1.00 60.00 120.00
+	7 1 1.00 60.00 120.00
+	 5250 3150 5250 2400
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+	 5100 1800 5400 1800 5400 2400 5100 2400 5100 1800
+4 1 -1 0 0 0 10 0.0000 2 75 75 6000 2745 a\001
+4 1 -1 0 0 0 10 0.0000 2 75 75 6000 2445 c\001
+4 1 -1 0 0 0 12 0.0000 2 135 315 5100 5325 exit\001
+4 1 -1 0 0 0 12 0.0000 2 135 135 3300 3075 A\001
+4 1 -1 0 0 0 12 0.0000 2 135 795 3300 4875 condition\001
+4 1 -1 0 0 0 12 0.0000 2 135 135 3300 5100 B\001
+4 0 -1 0 0 0 12 0.0000 2 135 420 6600 3675 stack\001
+4 0 -1 0 0 0 12 0.0000 2 180 750 6600 3225 acceptor/\001
+4 0 -1 0 0 0 12 0.0000 2 180 750 6600 3450 signalled\001
+4 1 -1 0 0 0 12 0.0000 2 135 795 3300 2850 condition\001
+4 1 -1 0 0 0 12 0.0000 2 165 420 6000 1350 entry\001
+4 1 -1 0 0 0 12 0.0000 2 135 495 6000 1575 queue\001
+4 0 -1 0 0 0 12 0.0000 2 135 525 6300 2400 arrival\001
+4 0 -1 0 0 0 12 0.0000 2 135 630 6300 2175 order of\001
+4 1 -1 0 0 0 12 0.0000 2 135 525 5100 3675 shared\001
+4 1 -1 0 0 0 12 0.0000 2 135 735 5100 3975 variables\001
+4 0 0 50 -1 0 11 0.0000 2 165 855 4275 3150 Acceptables\001
Index: doc/proposals/concurrency/ext_monitor.fig.bak
===================================================================
--- doc/proposals/concurrency/ext_monitor.fig.bak	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
+++ doc/proposals/concurrency/ext_monitor.fig.bak	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
@@ -0,0 +1,95 @@
+#FIG 3.2  Produced by xfig version 3.2.5c
+Landscape
+Center
+Inches
+Letter  
+100.00
+Single
+-2
+1200 2
+5 1 0 1 -1 -1 0 0 -1 0.000 0 1 0 0 3150.000 3450.000 3150 3150 2850 3450 3150 3750
+5 1 0 1 -1 -1 0 0 -1 0.000 0 1 0 0 3150.000 4350.000 3150 4050 2850 4350 3150 4650
+6 5850 1950 6150 2250
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6000 2100 105 105 6000 2100 6105 2205
+4 1 -1 0 0 0 10 0.0000 2 105 90 6000 2160 d\001
+-6
+6 5850 1650 6150 1950
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6000 1800 105 105 6000 1800 6105 1905
+4 1 -1 0 0 0 10 0.0000 2 105 90 6000 1860 b\001
+-6
+6 5100 1800 5400 2100
+1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 5250 1950 105 105 5250 1950 5355 1950
+4 1 -1 0 0 0 10 0.0000 2 105 120 5250 2010 Y\001
+-6
+6 5100 2100 5400 2400
+1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 5250 2250 105 105 5250 2250 5355 2250
+4 1 -1 0 0 0 10 0.0000 2 105 120 5250 2295 X\001
+-6
+6 3000 5400 7200 5700
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 3150 5550 80 80 3150 5550 3230 5630
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4500 5550 105 105 4500 5550 4605 5655
+1 3 0 1 -1 -1 0 0 4 0.000 1 0.0000 6000 5550 105 105 6000 5550 6105 5655
+4 0 -1 0 0 0 12 0.0000 2 135 1035 4725 5625 blocked task\001
+4 0 -1 0 0 0 12 0.0000 2 135 870 3300 5625 active task\001
+4 0 -1 0 0 0 12 0.0000 2 180 930 6225 5625 routine ptrs\001
+-6
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3300 3600 105 105 3300 3600 3405 3705
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3600 3600 105 105 3600 3600 3705 3705
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6600 3900 105 105 6600 3900 6705 4005
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6900 3900 105 105 6900 3900 7005 4005
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6000 2700 105 105 6000 2700 6105 2805
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6000 2400 105 105 6000 2400 6105 2505
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 5100 4575 80 80 5100 4575 5180 4655
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+	 4050 2925 5475 2925 5475 3225 4050 3225 4050 2925
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+	 5850 2850 6075 3000
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4
+	 3150 3750 3750 3750 3750 4050 3150 4050
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3
+	 3150 3450 3750 3450 3900 3675
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+	 3750 3150 3600 3375
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3
+	 3150 4350 3750 4350 3900 4575
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+	 3750 4050 3600 4275
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4
+	 3150 4650 3750 4650 3750 4950 4950 4950
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+	 6450 3750 6300 3975
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+	 4950 4950 5175 5100
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 9
+	 5250 4950 6450 4950 6450 4050 7050 4050 7050 3750 6450 3750
+	 6450 2850 6150 2850 6150 1650
+2 2 1 1 -1 -1 0 0 -1 4.000 0 0 0 0 0 5
+	 5850 4200 5850 3300 4350 3300 4350 4200 5850 4200
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3
+	 5250 2850 5850 2850 5850 1650
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4
+	 3150 3150 3750 3150 3750 2850 5325 2850
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
+	1 1 1.00 60.00 120.00
+	7 1 1.00 60.00 120.00
+	 5250 3150 5250 2400
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+	 5100 1800 5400 1800 5400 2400 5100 2400 5100 1800
+4 0 0 50 -1 0 11 0.0000 2 150 795 4275 3150 Queues Ptr\001
+4 1 -1 0 0 0 10 0.0000 2 75 75 6000 2745 a\001
+4 1 -1 0 0 0 10 0.0000 2 75 75 6000 2445 c\001
+4 1 -1 0 0 0 12 0.0000 2 135 315 5100 5325 exit\001
+4 1 -1 0 0 0 12 0.0000 2 135 135 3300 3075 A\001
+4 1 -1 0 0 0 12 0.0000 2 135 795 3300 4875 condition\001
+4 1 -1 0 0 0 12 0.0000 2 135 135 3300 5100 B\001
+4 0 -1 0 0 0 12 0.0000 2 135 420 6600 3675 stack\001
+4 0 -1 0 0 0 12 0.0000 2 180 750 6600 3225 acceptor/\001
+4 0 -1 0 0 0 12 0.0000 2 180 750 6600 3450 signalled\001
+4 1 -1 0 0 0 12 0.0000 2 135 795 3300 2850 condition\001
+4 1 -1 0 0 0 12 0.0000 2 165 420 6000 1350 entry\001
+4 1 -1 0 0 0 12 0.0000 2 135 495 6000 1575 queue\001
+4 0 -1 0 0 0 12 0.0000 2 135 525 6300 2400 arrival\001
+4 0 -1 0 0 0 12 0.0000 2 135 630 6300 2175 order of\001
+4 1 -1 0 0 0 12 0.0000 2 135 525 5100 3675 shared\001
+4 1 -1 0 0 0 12 0.0000 2 135 735 5100 3975 variables\001
+4 0 0 50 -1 0 11 0.0000 2 165 855 4125 2175 Acceptables\001
Index: c/proposals/concurrency/figures/ext_monitor.fig
===================================================================
--- doc/proposals/concurrency/figures/ext_monitor.fig	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ 	(revision )
@@ -1,94 +1,0 @@
-#FIG 3.2  Produced by xfig version 3.2.5c
-Landscape
-Center
-Inches
-Letter  
-100.00
-Single
--2
-1200 2
-5 1 0 1 -1 -1 0 0 -1 0.000 0 1 0 0 3150.000 3450.000 3150 3150 2850 3450 3150 3750
-5 1 0 1 -1 -1 0 0 -1 0.000 0 1 0 0 3150.000 4350.000 3150 4050 2850 4350 3150 4650
-6 5850 1950 6150 2250
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6000 2100 105 105 6000 2100 6105 2205
-4 1 -1 0 0 0 10 0.0000 2 105 90 6000 2160 d\001
--6
-6 5850 1650 6150 1950
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6000 1800 105 105 6000 1800 6105 1905
-4 1 -1 0 0 0 10 0.0000 2 105 90 6000 1860 b\001
--6
-6 5100 1800 5400 2100
-1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 5250 1950 105 105 5250 1950 5355 1950
-4 1 -1 0 0 0 10 0.0000 2 105 120 5250 2010 Y\001
--6
-6 5100 2100 5400 2400
-1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 5250 2250 105 105 5250 2250 5355 2250
-4 1 -1 0 0 0 10 0.0000 2 105 120 5250 2295 X\001
--6
-6 3000 5400 7200 5700
-1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 3150 5550 80 80 3150 5550 3230 5630
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4500 5550 105 105 4500 5550 4605 5655
-1 3 0 1 -1 -1 0 0 4 0.000 1 0.0000 6000 5550 105 105 6000 5550 6105 5655
-4 0 -1 0 0 0 12 0.0000 2 135 1035 4725 5625 blocked task\001
-4 0 -1 0 0 0 12 0.0000 2 135 870 3300 5625 active task\001
-4 0 -1 0 0 0 12 0.0000 2 180 930 6225 5625 routine ptrs\001
--6
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3300 3600 105 105 3300 3600 3405 3705
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3600 3600 105 105 3600 3600 3705 3705
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6600 3900 105 105 6600 3900 6705 4005
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6900 3900 105 105 6900 3900 7005 4005
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6000 2700 105 105 6000 2700 6105 2805
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6000 2400 105 105 6000 2400 6105 2505
-1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 5100 4575 80 80 5100 4575 5180 4655
-2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
-	 4050 2925 5475 2925 5475 3225 4050 3225 4050 2925
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
-	 5850 2850 6075 3000
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4
-	 3150 3750 3750 3750 3750 4050 3150 4050
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3
-	 3150 3450 3750 3450 3900 3675
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
-	 3750 3150 3600 3375
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3
-	 3150 4350 3750 4350 3900 4575
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
-	 3750 4050 3600 4275
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4
-	 3150 4650 3750 4650 3750 4950 4950 4950
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
-	 6450 3750 6300 3975
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
-	 4950 4950 5175 5100
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 9
-	 5250 4950 6450 4950 6450 4050 7050 4050 7050 3750 6450 3750
-	 6450 2850 6150 2850 6150 1650
-2 2 1 1 -1 -1 0 0 -1 4.000 0 0 0 0 0 5
-	 5850 4200 5850 3300 4350 3300 4350 4200 5850 4200
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3
-	 5250 2850 5850 2850 5850 1650
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4
-	 3150 3150 3750 3150 3750 2850 5325 2850
-2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
-	1 1 1.00 60.00 120.00
-	7 1 1.00 60.00 120.00
-	 5250 3150 5250 2400
-2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
-	 5100 1800 5400 1800 5400 2400 5100 2400 5100 1800
-4 1 -1 0 0 0 10 0.0000 2 75 75 6000 2745 a\001
-4 1 -1 0 0 0 10 0.0000 2 75 75 6000 2445 c\001
-4 1 -1 0 0 0 12 0.0000 2 135 315 5100 5325 exit\001
-4 1 -1 0 0 0 12 0.0000 2 135 135 3300 3075 A\001
-4 1 -1 0 0 0 12 0.0000 2 135 795 3300 4875 condition\001
-4 1 -1 0 0 0 12 0.0000 2 135 135 3300 5100 B\001
-4 0 -1 0 0 0 12 0.0000 2 135 420 6600 3675 stack\001
-4 0 -1 0 0 0 12 0.0000 2 180 750 6600 3225 acceptor/\001
-4 0 -1 0 0 0 12 0.0000 2 180 750 6600 3450 signalled\001
-4 1 -1 0 0 0 12 0.0000 2 135 795 3300 2850 condition\001
-4 1 -1 0 0 0 12 0.0000 2 165 420 6000 1350 entry\001
-4 1 -1 0 0 0 12 0.0000 2 135 495 6000 1575 queue\001
-4 0 -1 0 0 0 12 0.0000 2 135 525 6300 2400 arrival\001
-4 0 -1 0 0 0 12 0.0000 2 135 630 6300 2175 order of\001
-4 1 -1 0 0 0 12 0.0000 2 135 525 5100 3675 shared\001
-4 1 -1 0 0 0 12 0.0000 2 135 735 5100 3975 variables\001
-4 0 0 50 -1 0 11 0.0000 2 165 855 4275 3150 Acceptables\001
Index: c/proposals/concurrency/figures/monitor.fig
===================================================================
--- doc/proposals/concurrency/figures/monitor.fig	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ 	(revision )
@@ -1,101 +1,0 @@
-#FIG 3.2  Produced by xfig version 3.2.5c
-Landscape
-Center
-Inches
-Letter  
-100.00
-Single
--2
-1200 2
-5 1 0 1 -1 -1 0 0 -1 0.000 0 1 0 0 1500.000 2700.000 1500 2400 1200 2700 1500 3000
-5 1 0 1 -1 -1 0 0 -1 0.000 0 1 0 0 1500.000 3600.000 1500 3300 1200 3600 1500 3900
-6 4200 1200 4500 1500
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4350 1350 105 105 4350 1350 4455 1455
-4 1 -1 0 0 0 10 0.0000 2 105 90 4350 1410 d\001
--6
-6 4200 900 4500 1200
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4350 1050 105 105 4350 1050 4455 1155
-4 1 -1 0 0 0 10 0.0000 2 105 90 4350 1110 b\001
--6
-6 2400 1500 2700 1800
-1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 2550 1650 105 105 2550 1650 2655 1650
-4 1 -1 0 0 0 10 0.0000 2 105 90 2550 1710 b\001
--6
-6 2400 1800 2700 2100
-1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 2550 1950 105 105 2550 1950 2655 1950
-4 1 -1 0 0 0 10 0.0000 2 75 75 2550 1995 a\001
--6
-6 3300 1500 3600 1800
-1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 3450 1650 105 105 3450 1650 3555 1650
-4 1 -1 0 0 0 10 0.0000 2 105 90 3450 1710 d\001
--6
-6 1350 4650 5325 4950
-1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 1500 4800 80 80 1500 4800 1580 4880
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 2850 4800 105 105 2850 4800 2955 4905
-1 3 0 1 -1 -1 0 0 4 0.000 1 0.0000 4350 4800 105 105 4350 4800 4455 4905
-4 0 -1 0 0 0 12 0.0000 2 180 765 4575 4875 duplicate\001
-4 0 -1 0 0 0 12 0.0000 2 135 1035 3075 4875 blocked task\001
-4 0 -1 0 0 0 12 0.0000 2 135 870 1650 4875 active task\001
--6
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 1650 2850 105 105 1650 2850 1755 2955
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 1950 2850 105 105 1950 2850 2055 2955
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4950 3150 105 105 4950 3150 5055 3255
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 5250 3150 105 105 5250 3150 5355 3255
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4350 1950 105 105 4350 1950 4455 2055
-1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4350 1650 105 105 4350 1650 4455 1755
-1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 3450 3825 80 80 3450 3825 3530 3905
-1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 3450 1950 105 105 3450 1950 3555 1950
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
-	 2400 2100 2625 2250
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
-	 3300 2100 3525 2250
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
-	 4200 2100 4425 2250
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 5
-	 1500 2400 2100 2400 2100 2100 2400 2100 2400 1500
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4
-	 1500 3000 2100 3000 2100 3300 1500 3300
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3
-	 1500 2700 2100 2700 2250 2925
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
-	 2100 2400 1950 2625
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3
-	 1500 3600 2100 3600 2250 3825
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
-	 2100 3300 1950 3525
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4
-	 1500 3900 2100 3900 2100 4200 3300 4200
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
-	 4800 3000 4650 3225
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
-	 3300 4200 3525 4350
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4
-	 3600 1500 3600 2100 4200 2100 4200 900
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4
-	 2700 1500 2700 2100 3300 2100 3300 1500
-2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 9
-	 3600 4200 4800 4200 4800 3300 5400 3300 5400 3000 4800 3000
-	 4800 2100 4500 2100 4500 900
-2 2 1 1 -1 -1 0 0 -1 4.000 0 0 0 0 0 5
-	 4200 3450 4200 2550 2700 2550 2700 3450 4200 3450
-4 1 -1 0 0 0 10 0.0000 2 75 75 4350 1995 a\001
-4 1 -1 0 0 0 10 0.0000 2 75 75 4350 1695 c\001
-4 1 -1 0 0 0 12 0.0000 2 135 315 3450 4575 exit\001
-4 1 -1 0 0 0 12 0.0000 2 135 135 1650 2325 A\001
-4 1 -1 0 0 0 12 0.0000 2 135 795 1650 4125 condition\001
-4 1 -1 0 0 0 12 0.0000 2 135 135 1650 4350 B\001
-4 0 -1 0 0 0 12 0.0000 2 135 420 4950 2925 stack\001
-4 0 -1 0 0 0 12 0.0000 2 180 750 4950 2475 acceptor/\001
-4 0 -1 0 0 0 12 0.0000 2 180 750 4950 2700 signalled\001
-4 1 -1 0 0 0 12 0.0000 2 135 795 1650 2100 condition\001
-4 1 -1 0 0 0 12 0.0000 2 135 135 2550 1425 X\001
-4 1 -1 0 0 0 12 0.0000 2 135 135 3450 1425 Y\001
-4 1 -1 0 0 0 12 0.0000 2 165 420 4350 600 entry\001
-4 1 -1 0 0 0 12 0.0000 2 135 495 4350 825 queue\001
-4 0 -1 0 0 0 12 0.0000 2 135 525 4650 1650 arrival\001
-4 0 -1 0 0 0 12 0.0000 2 135 630 4650 1425 order of\001
-4 1 -1 0 0 0 12 0.0000 2 135 525 3450 2925 shared\001
-4 1 -1 0 0 0 12 0.0000 2 135 735 3450 3225 variables\001
-4 1 -1 0 0 0 12 0.0000 2 120 510 3000 975 mutex\001
-4 1 -1 0 0 0 10 0.0000 2 75 75 3450 1995 c\001
-4 1 -1 0 0 0 12 0.0000 2 135 570 3000 1200 queues\001
Index: doc/proposals/concurrency/glossary.tex
===================================================================
--- doc/proposals/concurrency/glossary.tex	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
+++ doc/proposals/concurrency/glossary.tex	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
@@ -0,0 +1,102 @@
+\makeglossaries
+
+\longnewglossaryentry{callsite-locking}
+{name={callsite-locking}}
+{
+Locking done by the calling routine. With this technique, a routine calling a monitor routine will aquire the monitor \emph{before} making the call to the actuall routine.
+}
+
+\longnewglossaryentry{entry-point-locking}
+{name={entry-point-locking}}
+{
+Locking done by the called routine. With this technique, a monitor routine called by another routine will aquire the monitor \emph{after} entering the routine body but prior to any other code.
+}
+
+\longnewglossaryentry{group-acquire}
+{name={bulk acquiring}}
+{
+Implicitly acquiring several monitors when entering a monitor.
+}
+
+\longnewglossaryentry{mon-ctx}
+{name={monitor context}}
+{
+The state of the current thread regarding which monitors are owned.
+}
+
+
+\longnewglossaryentry{uthread}
+{name={user-level thread}}
+{
+Threads created and managed inside user-space. Each thread has its own stack and its own thread of execution. User-level threads are insisible to the underlying operating system.
+
+\textit{Synonyms : User threads, Lightweight threads, Green threads, Virtual threads, Tasks.}
+}
+
+\longnewglossaryentry{kthread}
+{name={kernel-level thread}}
+{
+Threads created and managed inside kernel-space. Each thread has its own stack and its own thread of execution. Kernel-level threads are owned, managed and scheduled by the underlying operating system.
+
+\textit{Synonyms : OS threads, Hardware threads, Physical threads.}
+}
+
+\longnewglossaryentry{fiber}
+{name={fiber}}
+{
+Fibers are non-preemptive user-level threads. They share most of the caracteristics of user-level threads except that they cannot be preempted by an other fiber.
+
+\textit{Synonyms : Tasks.}
+}
+
+\longnewglossaryentry{job}
+{name={job}}
+{
+Unit of work, often send to a thread pool or worker pool to be executed. Has neither its own stack or its own thread of execution.
+
+\textit{Synonyms : Tasks.}
+}
+
+\longnewglossaryentry{pool}
+{name={thread-pool}}
+{
+Group of homogeneuous threads that loop executing units of works after another.
+
+\textit{Synonyms : }
+}
+
+\longnewglossaryentry{cfacluster}
+{name={cluster}}
+{
+TBD...
+
+\textit{Synonyms : None.}
+}
+
+\longnewglossaryentry{cfacpu}
+{name={processor}}
+{
+TBD...
+
+\textit{Synonyms : None.}
+}
+
+\longnewglossaryentry{cfathread}
+{name={thread}}
+{
+TBD...
+
+\textit{Synonyms : None.}
+}
+
+\longnewglossaryentry{preemption}
+{name={preemption}}
+{
+TBD...
+
+\textit{Synonyms : None.}
+}
+
+\newacronym{tls}{TLS}{Thread Local Storage}
+\newacronym{api}{API}{Application Program Interface}
+\newacronym{raii}{RAII}{Ressource Acquisition Is Initialization}
Index: doc/proposals/concurrency/lit-review.md
===================================================================
--- doc/proposals/concurrency/lit-review.md	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
+++ doc/proposals/concurrency/lit-review.md	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
@@ -0,0 +1,25 @@
+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/proposals/concurrency/local.bib
===================================================================
--- doc/proposals/concurrency/local.bib	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
+++ doc/proposals/concurrency/local.bib	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
@@ -0,0 +1,40 @@
+%    Predefined journal names:
+%  acmcs: Computing Surveys		acta: Acta Infomatica
+%  cacm: Communications of the ACM
+%  ibmjrd: IBM J. Research & Development ibmsj: IBM Systems Journal
+%  ieeese: IEEE Trans. on Soft. Eng.	ieeetc: IEEE Trans. on Computers
+%  ieeetcad: IEEE Trans. on Computer-Aided Design of Integrated Circuits
+%  ipl: Information Processing Letters	jacm: Journal of the ACM
+%  jcss: J. Computer & System Sciences	scp: Science of Comp. Programming
+%  sicomp: SIAM J. on Computing		tocs: ACM Trans. on Comp. Systems
+%  tods: ACM Trans. on Database Sys.	tog: ACM Trans. on Graphics
+%  toms: ACM Trans. on Math. Software	toois: ACM Trans. on Office Info. Sys.
+%  toplas: ACM Trans. on Prog. Lang. & Sys.
+%  tcs: Theoretical Computer Science
+@string{ieeepds="IEEE Transactions on Parallel and Distributed Systems"}
+@string{ieeese="IEEE Transactions on Software Engineering"}
+@string{spe="Software---\-Practice and Experience"}
+@string{sigplan="SIGPLAN Notices"}
+@string{joop="Journal of Object-Oriented Programming"}
+@string{popl="Conference Record of the ACM Symposium on Principles of Programming Languages"}
+@string{osr="Operating Systems Review"}
+@string{pldi="Programming Language Design and Implementation"}
+
+
+@article{HPP:Study,
+	keywords 	= {Parallel, Productivity},
+	author 	= {Lorin Hochstein and Jeff Carver and Forrest Shull and Sima Asgari and Victor Basili and Jeffrey K. Hollingsworth and Marvin V. Zelkowitz },
+	title 	= {Parallel Programmer Productivity: A Case Study of Novice Parallel Programmers},
+}
+
+@article{Chicken,
+	keywords	= {Chicken},
+	author	= {Doug Zongker},
+	title		= {Chicken Chicken Chicken: Chicken Chicken},
+	year		= 2006
+}
+
+@article{TBB,
+	keywords 	= {Intel, TBB},
+	title 	= {Intel Thread Building Blocks},
+}
Index: doc/proposals/concurrency/monitor.fig
===================================================================
--- doc/proposals/concurrency/monitor.fig	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
+++ doc/proposals/concurrency/monitor.fig	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
@@ -0,0 +1,101 @@
+#FIG 3.2  Produced by xfig version 3.2.5c
+Landscape
+Center
+Inches
+Letter  
+100.00
+Single
+-2
+1200 2
+5 1 0 1 -1 -1 0 0 -1 0.000 0 1 0 0 1500.000 2700.000 1500 2400 1200 2700 1500 3000
+5 1 0 1 -1 -1 0 0 -1 0.000 0 1 0 0 1500.000 3600.000 1500 3300 1200 3600 1500 3900
+6 4200 1200 4500 1500
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4350 1350 105 105 4350 1350 4455 1455
+4 1 -1 0 0 0 10 0.0000 2 105 90 4350 1410 d\001
+-6
+6 4200 900 4500 1200
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4350 1050 105 105 4350 1050 4455 1155
+4 1 -1 0 0 0 10 0.0000 2 105 90 4350 1110 b\001
+-6
+6 2400 1500 2700 1800
+1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 2550 1650 105 105 2550 1650 2655 1650
+4 1 -1 0 0 0 10 0.0000 2 105 90 2550 1710 b\001
+-6
+6 2400 1800 2700 2100
+1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 2550 1950 105 105 2550 1950 2655 1950
+4 1 -1 0 0 0 10 0.0000 2 75 75 2550 1995 a\001
+-6
+6 3300 1500 3600 1800
+1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 3450 1650 105 105 3450 1650 3555 1650
+4 1 -1 0 0 0 10 0.0000 2 105 90 3450 1710 d\001
+-6
+6 1350 4650 5325 4950
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 1500 4800 80 80 1500 4800 1580 4880
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 2850 4800 105 105 2850 4800 2955 4905
+1 3 0 1 -1 -1 0 0 4 0.000 1 0.0000 4350 4800 105 105 4350 4800 4455 4905
+4 0 -1 0 0 0 12 0.0000 2 180 765 4575 4875 duplicate\001
+4 0 -1 0 0 0 12 0.0000 2 135 1035 3075 4875 blocked task\001
+4 0 -1 0 0 0 12 0.0000 2 135 870 1650 4875 active task\001
+-6
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 1650 2850 105 105 1650 2850 1755 2955
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 1950 2850 105 105 1950 2850 2055 2955
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4950 3150 105 105 4950 3150 5055 3255
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 5250 3150 105 105 5250 3150 5355 3255
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4350 1950 105 105 4350 1950 4455 2055
+1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4350 1650 105 105 4350 1650 4455 1755
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 3450 3825 80 80 3450 3825 3530 3905
+1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 3450 1950 105 105 3450 1950 3555 1950
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+	 2400 2100 2625 2250
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+	 3300 2100 3525 2250
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+	 4200 2100 4425 2250
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 5
+	 1500 2400 2100 2400 2100 2100 2400 2100 2400 1500
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4
+	 1500 3000 2100 3000 2100 3300 1500 3300
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3
+	 1500 2700 2100 2700 2250 2925
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+	 2100 2400 1950 2625
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3
+	 1500 3600 2100 3600 2250 3825
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+	 2100 3300 1950 3525
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4
+	 1500 3900 2100 3900 2100 4200 3300 4200
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+	 4800 3000 4650 3225
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+	 3300 4200 3525 4350
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4
+	 3600 1500 3600 2100 4200 2100 4200 900
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4
+	 2700 1500 2700 2100 3300 2100 3300 1500
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 9
+	 3600 4200 4800 4200 4800 3300 5400 3300 5400 3000 4800 3000
+	 4800 2100 4500 2100 4500 900
+2 2 1 1 -1 -1 0 0 -1 4.000 0 0 0 0 0 5
+	 4200 3450 4200 2550 2700 2550 2700 3450 4200 3450
+4 1 -1 0 0 0 10 0.0000 2 75 75 4350 1995 a\001
+4 1 -1 0 0 0 10 0.0000 2 75 75 4350 1695 c\001
+4 1 -1 0 0 0 12 0.0000 2 135 315 3450 4575 exit\001
+4 1 -1 0 0 0 12 0.0000 2 135 135 1650 2325 A\001
+4 1 -1 0 0 0 12 0.0000 2 135 795 1650 4125 condition\001
+4 1 -1 0 0 0 12 0.0000 2 135 135 1650 4350 B\001
+4 0 -1 0 0 0 12 0.0000 2 135 420 4950 2925 stack\001
+4 0 -1 0 0 0 12 0.0000 2 180 750 4950 2475 acceptor/\001
+4 0 -1 0 0 0 12 0.0000 2 180 750 4950 2700 signalled\001
+4 1 -1 0 0 0 12 0.0000 2 135 795 1650 2100 condition\001
+4 1 -1 0 0 0 12 0.0000 2 135 135 2550 1425 X\001
+4 1 -1 0 0 0 12 0.0000 2 135 135 3450 1425 Y\001
+4 1 -1 0 0 0 12 0.0000 2 165 420 4350 600 entry\001
+4 1 -1 0 0 0 12 0.0000 2 135 495 4350 825 queue\001
+4 0 -1 0 0 0 12 0.0000 2 135 525 4650 1650 arrival\001
+4 0 -1 0 0 0 12 0.0000 2 135 630 4650 1425 order of\001
+4 1 -1 0 0 0 12 0.0000 2 135 525 3450 2925 shared\001
+4 1 -1 0 0 0 12 0.0000 2 135 735 3450 3225 variables\001
+4 1 -1 0 0 0 12 0.0000 2 120 510 3000 975 mutex\001
+4 1 -1 0 0 0 10 0.0000 2 75 75 3450 1995 c\001
+4 1 -1 0 0 0 12 0.0000 2 135 570 3000 1200 queues\001
Index: doc/proposals/concurrency/notes.md
===================================================================
--- doc/proposals/concurrency/notes.md	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
+++ doc/proposals/concurrency/notes.md	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
@@ -0,0 +1,14 @@
+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
+ 
Index: c/proposals/concurrency/notes/cor-thread-traits.c
===================================================================
--- doc/proposals/concurrency/notes/cor-thread-traits.c	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ 	(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: c/proposals/concurrency/notes/lit-review.md
===================================================================
--- doc/proposals/concurrency/notes/lit-review.md	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ 	(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: c/proposals/concurrency/notes/notes.md
===================================================================
--- doc/proposals/concurrency/notes/notes.md	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ 	(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
- 
Index: doc/proposals/concurrency/style.tex
===================================================================
--- doc/proposals/concurrency/style.tex	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
+++ doc/proposals/concurrency/style.tex	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
@@ -0,0 +1,12 @@
+\input{common}                                          % bespoke macros used in the document
+\input{cfa-format}
+
+% \CFADefaultStyle
+
+\lstset{
+morekeywords=[2]{nomutex,mutex,thread,wait,wait_release,signal,signal_block,accept,monitor,suspend,resume,coroutine},
+keywordstyle=[2]\color{blue},				% second set of keywords for concurency
+basicstyle=\linespread{0.9}\tt\small,		% reduce line spacing and use typewriter font
+stringstyle=\sf\color{Mahogany},			% use sanserif font
+commentstyle=\itshape\color{OliveGreen},		% green and italic comments
+}%
Index: c/proposals/concurrency/style/cfa-format.tex
===================================================================
--- doc/proposals/concurrency/style/cfa-format.tex	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ 	(revision )
@@ -1,233 +1,0 @@
-\usepackage[usenames,dvipsnames]{xcolor}
-\usepackage{listings}
-\usepackage{inconsolata}
-
-\definecolor{basicCol}{HTML}{000000}
-\definecolor{commentCol}{HTML}{000000}
-\definecolor{stringCol}{HTML}{000000}
-\definecolor{keywordCol}{HTML}{000000}
-\definecolor{identifierCol}{HTML}{000000}
-
-% from https://gist.github.com/nikolajquorning/92bbbeef32e1dd80105c9bf2daceb89a
-\lstdefinelanguage{sml} {
-  morekeywords= {
-    EQUAL, GREATER, LESS, NONE, SOME, abstraction, abstype, and, andalso, array, as, before, bool, case, char, datatype, do, else, end, eqtype, exception, exn, false, fn, fun, functor, handle, if, in, include, infix, infixr, int, let, list, local, nil, nonfix, not, o, of, op, open, option, orelse, overload, print, raise, real, rec, ref, sharing, sig, signature, string, struct, structure, substring, then, true, type, unit, val, vector, where, while, with, withtype, word
-  },
-  morestring=[b]",
-  morecomment=[s]{(*}{*)},
-}
-
-\lstdefinelanguage{D}{
-  % Keywords
-  morekeywords=[1]{
-    abstract, alias, align, auto, body, break, cast, catch, class, const,
-    continue, debug, delegate, delete, deprecated, do, else, enum, export,
-    false, final, finally, for, foreach, foreach_reverse, function, goto, if,
-    immutable, import, in, inout, interface, invariant, is, lazy, macro, mixin,
-    module, new, nothrow, null, out, override, package, pragma, private,
-    protected, public, pure, ref, return, shared, static, struct, super,
-    switch, synchronized, template, this, throw, true, try, typedef, typeid,
-    typeof, union, unittest, volatile, while, with
-  },
-  % Special identifiers, common functions
-  morekeywords=[2]{enforce},
-  % Ugly identifiers
-  morekeywords=[3]{
-    __DATE__, __EOF__, __FILE__, __LINE__, __TIMESTAMP__, __TIME__, __VENDOR__,
-    __VERSION__, __ctfe, __gshared, __monitor, __thread, __vptr, _argptr,
-    _arguments, _ctor, _dtor
-  },
-  % Basic types
-  morekeywords=[4]{
-     byte, ubyte, short, ushort, int, uint, long, ulong, cent, ucent, void,
-     bool, bit, float, double, real, ushort, int, uint, long, ulong, float,
-     char, wchar, dchar, string, wstring, dstring, ireal, ifloat, idouble,
-     creal, cfloat, cdouble, size_t, ptrdiff_t, sizediff_t, equals_t, hash_t
-  },
-  % Strings
-  morestring=[b]{"},
-  morestring=[b]{'},
-  morestring=[b]{`},
-  % Comments
-  comment=[l]{//},
-  morecomment=[s]{/*}{*/},
-  morecomment=[s][\color{blue}]{/**}{*/},
-  morecomment=[n]{/+}{+/},
-  morecomment=[n][\color{blue}]{/++}{+/},
-  % Options
-  sensitive=true
-}
-
-\lstdefinelanguage{rust}{
-  % Keywords
-  morekeywords=[1]{
-    abstract, alignof, as, become, box,
-    break, const, continue, crate, do,
-    else, enum, extern, false, final,
-    fn, for, if, impl, in,
-    let, loop, macro, match, mod,
-    move, mut, offsetof, override, priv,
-    proc, pub, pure, ref, return,
-    Self, self, sizeof, static, struct,
-    super, trait, true,  type, typeof,
-    unsafe, unsized, use, virtual, where,
-    while, yield
-  },
-  % Strings
-  morestring=[b]{"},
-  % Comments
-  comment=[l]{//},
-  morecomment=[s]{/*}{*/},
-  % Options
-  sensitive=true
-}
-
-\lstdefinelanguage{pseudo}{
-	morekeywords={string,uint,int,bool,float},%
-	sensitive=true,%
-	morecomment=[l]{//},%
-	morecomment=[s]{/*}{*/},%
-	morestring=[b]',%
-	morestring=[b]",%
-	morestring=[s]{`}{`},%
-}%
-
-\newcommand{\KWC}{K-W C\xspace}
-
-\lstdefinestyle{pseudoStyle}{
-  escapeinside={@@},
-  basicstyle=\linespread{0.9}\sf\footnotesize,		% reduce line spacing and use typewriter font
-  keywordstyle=\bfseries\color{blue},
-  keywordstyle=[2]\bfseries\color{Plum},
-  commentstyle=\itshape\color{OliveGreen},		    % green and italic comments
-  identifierstyle=\color{identifierCol},
-  stringstyle=\sf\color{Mahogany},			          % use sanserif font
-  mathescape=true,
-  columns=fixed,
-  aboveskip=4pt,                                  % spacing above/below code block
-  belowskip=3pt,
-  keepspaces=true,
-  % frame=lines,
-  literate=,
-  showlines=true,                                 % show blank lines at end of code
-  showspaces=false,
-  showstringspaces=false,
-  escapechar=\$,
-  xleftmargin=\parindentlnth,                     % indent code to paragraph indentation
-  moredelim=[is][\color{red}\bfseries]{**R**}{**R**},    % red highlighting
-  % moredelim=* detects keywords, comments, strings, and other delimiters and applies their formatting
-  % moredelim=** allows cumulative application
-}
-
-\lstdefinestyle{defaultStyle}{
-  escapeinside={@@},
-  basicstyle=\linespread{0.9}\tt\footnotesize,		% reduce line spacing and use typewriter font
-  keywordstyle=\bfseries\color{blue},
-  keywordstyle=[2]\bfseries\color{Plum},
-  commentstyle=\itshape\color{OliveGreen},		    % green and italic comments
-  identifierstyle=\color{identifierCol},
-  stringstyle=\sf\color{Mahogany},			          % use sanserif font
-  mathescape=true,
-  columns=fixed,
-  aboveskip=4pt,                                  % spacing above/below code block
-  belowskip=3pt,
-  keepspaces=true,
-  % frame=lines,
-  literate=,
-  showlines=true,                                 % show blank lines at end of code
-  showspaces=false,
-  showstringspaces=false,
-  escapechar=\$,
-  xleftmargin=\parindentlnth,                     % indent code to paragraph indentation
-  moredelim=[is][\color{red}\bfseries]{**R**}{**R**},    % red highlighting
-  % moredelim=* detects keywords, comments, strings, and other delimiters and applies their formatting
-  % moredelim=** allows cumulative application
-}
-
-\lstMakeShortInline[basewidth=0.5em,breaklines=true,basicstyle=\normalsize\ttfamily\color{basicCol}]@  % single-character for \lstinline
-
-\lstnewenvironment{ccode}[1][]{
-  \lstset{
-    language = C,
-    style=defaultStyle,
-    #1
-  }
-}{}
-
-\lstnewenvironment{cfacode}[1][]{
-  \lstset{
-    language = CFA,
-    style=defaultStyle,
-    #1
-  }
-}{}
-
-\lstnewenvironment{pseudo}[1][]{
-  \lstset{
-    language = pseudo,
-    style=pseudoStyle,
-    #1
-  }
-}{}
-
-\lstnewenvironment{cppcode}[1][]{
-  \lstset{
-    language = c++,
-    style=defaultStyle,
-    #1
-  }
-}{}
-
-\lstnewenvironment{ucppcode}[1][]{
-  \lstset{
-    language = c++,
-    style=defaultStyle,
-    #1
-  }
-}{}
-
-\lstnewenvironment{javacode}[1][]{
-  \lstset{
-    language = java,
-    style=defaultStyle,
-    #1
-  }
-}{}
-
-\lstnewenvironment{scalacode}[1][]{
-  \lstset{
-    language = scala,
-    style=defaultStyle,
-    #1
-  }
-}{}
-
-\lstnewenvironment{smlcode}[1][]{
-  \lstset{
-    language = sml,
-    style=defaultStyle,
-    #1
-  }
-}{}
-
-\lstnewenvironment{dcode}[1][]{
-  \lstset{
-    language = D,
-    style=defaultStyle,
-    #1
-  }
-}{}
-
-\lstnewenvironment{rustcode}[1][]{
-  \lstset{
-    language = rust,
-    style=defaultStyle,
-    #1
-  }
-}{}
-
-\newcommand{\zero}{\lstinline{zero_t}\xspace}
-\newcommand{\one}{\lstinline{one_t}\xspace}
-\newcommand{\ateq}{\lstinline{\@=}\xspace}
-\newcommand{\code}[1]{\lstinline[language=CFA,style=defaultStyle]{#1}}
-\newcommand{\pscode}[1]{\lstinline[language=pseudo,style=pseudoStyle]{#1}}
Index: c/proposals/concurrency/style/style.tex
===================================================================
--- doc/proposals/concurrency/style/style.tex	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ 	(revision )
@@ -1,12 +1,0 @@
-\input{common}                                          % bespoke macros used in the document
-\input{cfa-format}
-
-% \CFADefaultStyle
-
-% \lstset{
-% morekeywords=[2]{nomutex,mutex,thread,wait,wait_release,signal,signal_block,accept,monitor,suspend,resume,coroutine},
-% keywordstyle=[2]\color{blue},				% second set of keywords for concurency
-% basicstyle=\linespread{0.9}\tt\small,		% reduce line spacing and use typewriter font
-% stringstyle=\sf\color{Mahogany},			% use sanserif font
-% commentstyle=\itshape\color{OliveGreen},		% green and italic comments
-% }%
Index: c/proposals/concurrency/text/basics.tex
===================================================================
--- doc/proposals/concurrency/text/basics.tex	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ 	(revision )
@@ -1,264 +1,0 @@
-% ======================================================================
-% ======================================================================
-\chapter{Basics}
-% ======================================================================
-% ======================================================================
-Before any detailed discussion of the concurrency and parallelism in \CFA, it is important to describe the basics of concurrency and how they are expressed in \CFA user code.
-
-\section{Basics of concurrency}
-At its core, concurrency is based on having multiple call stacks and potentially multiple threads of execution for these stacks. Concurrency alone without parallelism only requires having multiple call stacks (or contexts) for a single thread of execution and switching between these call stacks on a regular basis. A minimal concurrency product can be achieved by creating coroutines which instead of context switching between each other, always ask an oracle where to context switch next. While coroutines do not technically require a stack, stackfull coroutines are the closest abstraction to a practical "naked"" call stack. When writing concurrency in terms of coroutines, the oracle effectively becomes a scheduler and the whole system now follows a cooperative threading model \cit. The oracle/scheduler can either be a stackless or stackfull entity and correspondingly require one or two context switches to run a different coroutine but in any case a subset of concurrency related challenges start to appear. For the complete set of concurrency challenges to be present, the only feature missing is preemption. Indeed, concurrency challenges appear with the lack of determinism. Guaranteeing mutual-exclusion or synchronisation are simply ways of limiting the lack of determinism in the system. A scheduler introduces order of execution uncertainty while preemption introduces incertainty about when context-switches occur. Now it is important to understand that uncertainty is not necessarily undesireable, uncertainty can often be used by systems to significantly increase performance and is often the basis of giving the user the illusion that hundred of tasks are running in parallel. Optimal performance in concurrent applications is often obtained by having as little determinism as correctness will allow\cit.
-
-\section{\protect\CFA 's Thread Building Blocks}
-% As a system-level language, \CFA should offer both performance and flexibilty as its primary goals, simplicity and user-friendliness being a secondary concern. Therefore, the core of parallelism in \CFA should prioritize power and efficiency. With this said, deconstructing popular paradigms in order to get simple building blocks yields \glspl{uthread} as the core parallelism block. \Glspl{pool} and other parallelism paradigms can then be built on top of the underlying threading model.
-One of the important features that is missing to C is threading. On modern architectures, the lack of threading is becoming less and less forgivable\cite{Sutter05, Sutter05b} and therefore any modern programming language should have the proper tools to allow users to write performant concurrent and/or parallel programs. As an extension of C, \CFA needs to express these concepts an a way that is as natural as possible to programmers used to imperative languages. And being a system level language means programmers will expect to be able to choose precisely which features they need and which cost they are willing to pay.
-
-\section{Coroutines A stepping stone}\label{coroutine}
-While the main focus of this proposal is concurrency and parallelism, as mentionned above it is important to adress coroutines which are actually a significant underlying aspect of the concurrency system. Indeed, while having nothing todo with parallelism and arguably little to do with concurrency, coroutines need to deal with context-switchs and and other context management operations. Therefore, this proposal includes coroutines both as an intermediate step for the implementation of threads and a first class feature of \CFA. Furthermore, many design challenges of threads are at least partially present in designing coroutines, which makes the design effort that much more relevant. The core API of coroutines revolve around two features independent call stacks and \code{suspend}/\code{resume}.
-
-Here is an example of a solution to the fibonnaci problem using \CFA coroutines:
-\begin{cfacode}
-	coroutine Fibonacci {
-	      int fn; // used for communication
-	};
-
-	void ?{}(Fibonacci* this) { // constructor
-	      this->fn = 0;
-	}
-
-	void main(Fibonacci* this) {
-		int fn1, fn2; 		// retained between resumes
-		this->fn = 0;
-		fn1 = this->fn;
-		suspend(this); 		// return to last resume
-
-		this->fn = 1;
-		fn2 = fn1;
-		fn1 = this->fn;
-		suspend(this); 		// return to last resume
-
-		for ( ;; ) {
-			this->fn = fn1 + fn2;
-			fn2 = fn1;
-			fn1 = this->fn;
-			suspend(this); 	// return to last resume
-		}
-	}
-
-	int next(Fibonacci* this) {
-		resume(this); // transfer to last suspend
-		return this.fn;
-	}
-
-	void main() { // regular program main
-		Fibonacci f1, f2;
-		for ( int i = 1; i <= 10; i += 1 ) {
-			sout | next(&f1) | next(&f2) | endl;
-		}
-	}
-\end{cfacode}
-
-\subsection{Construction}
-One important design challenge for coroutines and threads (shown in section \ref{threads}) is that the runtime system needs to run some code after the user-constructor runs. In the case of the coroutines this challenge is simpler since there is no loss of determinism brough by preemption or scheduling, however, the underlying challenge remains the same for coroutines and threads.
-
-The runtime system needs to create the coroutine's stack and more importantly prepare it for the first resumption. The timing of the creation is non trivial since users both expect to have fully constructed objects once execution enters the coroutine main and to be able to resume the coroutine from the constructor (Obviously we only solve cases where these two statements don't conflict). There are several solutions to this problem but the chosen options effectively forces the design of the coroutine.
-
-Furthermore, \CFA faces an extra challenge which is that polymorphique routines rely on invisible thunks when casted to non-polymorphic routines and these thunks have function scope. For example, the following code, while looking benign, can run into undefined behaviour because of thunks:
-
-\begin{cfacode}
-//async: Runs function asynchronously on another thread
-forall(otype T)
-extern void async(void (*func)(T*), T* obj);
-
-forall(otype T)
-void noop(T *) {}
-
-void bar() {
-	int a;
-	async(noop, &a);
-}
-\end{cfacode}
-Indeed, the generated C code\footnote{Code trimmed down for brevity} shows that a local thunk is created in order to hold type information:
-
-\begin{ccode}
-extern void async(/* omitted */, void (*func)(void *), void *obj);
-
-void noop(/* omitted */, void *obj){}
-
-void bar(){
-	int a;
-	void _thunk0(int *_p0){
-		/* omitted */
-		noop(/* omitted */, _p0);
-	}
-	/* omitted */
-	async(/* omitted */, ((void (*)(void *))(&_thunk0)), (&a));
-}
-\end{ccode}
-The problem in the this example is that there is a race condition between the start of the execution of \code{noop} on the other thread and the stack frame of \code{bar} being destroyed. This extra challenge limits which solutions are viable because storing the function pointer for too long only increases the chances that the race will end in undefined behavior; i.e. the stack based thunk being destroyed before it was used.
-
-\subsection{Alternative: Composition}
-One solution to this challenge would be to use inheritence,
-
-\begin{cfacode}
-	struct Fibonacci {
-	      int fn; // used for communication
-	      coroutine c;
-	};
-
-	void ?{}(Fibonacci* this) {
-	      this->fn = 0;
-		(&this->c){};
-	}
-\end{cfacode}
-
-There are two downsides to this approach. The first, which is relatively minor, is that the base class needs to be made aware of the main routine pointer, regardless of whether we use a parameter or a virtual pointer, this means the coroutine data must be made larger to store a value that is actually a compile time constant (The address of the main routine). The second problem which is both subtle but significant, is that now users can get the initialisation order of there coroutines wrong. Indeed, every field of a \CFA struct will be constructed but in the order of declaration, unless users explicitly write otherwise. This means that users who forget to initialize a the coroutine at the right time may resume the coroutine with an uninitilized object. For coroutines, this is unlikely to be a problem, for threads however, this is a significant problem.
-
-\subsection{Alternative: Reserved keyword}
-The next alternative is to use language support to annotate coroutines as follows:
-
-\begin{cfacode}
-	coroutine Fibonacci {
-	      int fn; // used for communication
-	};
-\end{cfacode}
-
-This mean the compiler can solve problems by injecting code where needed. The downside of this approach is that it makes coroutine a special case in the language. Users who would want to extend coroutines or build their own for various reasons can only do so in ways offered by the language. Furthermore, implementing coroutines without language supports also displays the power of \CFA.
-While this is ultimately the option used for idiomatic \CFA code, coroutines and threads can both be constructed by users without using the language support. The reserved keywords are only present to improve ease of use for the common cases.
-
-\subsection{Alternative: Lamda Objects}
-
-For coroutines as for threads, many implementations are based on routine pointers or function objects\cit. For example, Boost implements coroutines in terms of four functor object types \code{asymmetric_coroutine<>::pull_type}, \code{asymmetric_coroutine<>::push_type}, \code{symmetric_coroutine<>::call_type}, \code{symmetric_coroutine<>::yield_type}. Often, the canonical threading paradigm in languages is based on function pointers, pthread being one of the most well known example. The main problem of these approach is that the thread usage is limited to a generic handle that must otherwise be wrapped in a custom type. Since the custom type is simple to write and \CFA and solves several issues, added support for routine/lambda based coroutines adds very little.
-
-\subsection{Trait based coroutines}
-
-Finally the underlying approach, which is the one closest to \CFA idioms, is to use trait-based lazy coroutines. This approach defines a coroutine as \say{anything that \say{satisfies the trait \code{is_coroutine} and is used as a coroutine} is a coroutine}. 
-
-\begin{cfacode}
-trait is_coroutine(dtype T) {
-      void main(T * this);
-      coroutine_desc * get_coroutine(T * this);
-};
-\end{cfacode}
-
-This entails that an object is not a coroutine until \code{resume} (or \code{prime}) is called on the object. Correspondingly, any object that is passed to \code{resume} is a coroutine since it must satisfy the \code{is_coroutine} trait to compile. The advantage of this approach is that users can easily create different types of coroutines, for example, changing the memory foot print of a coroutine is trivial when implementing the \code{get_coroutine} routine. The \CFA keyword \code{coroutine} only has the effect of implementing the getter and forward declarations required for users to only have to implement the main routine. 
-
-
-\section{Thread Interface}\label{threads}
-The basic building blocks of multi-threading in \CFA are \glspl{cfathread}. By default these are implemented as \glspl{uthread}, and as such, offer a flexible and lightweight threading interface (lightweight compared to \glspl{kthread}). A thread can be declared using a SUE declaration \code{thread} as follows:
-
-\begin{cfacode}
-	thread foo {};
-\end{cfacode}
-
-Like for coroutines, the keyword is a thin wrapper arount a \CFA trait:
-
-\begin{cfacode}
-trait is_thread(dtype T) {
-      void ^?{}(T* mutex this);
-      void main(T* this);
-      thread_desc* get_thread(T* this);
-};
-\end{cfacode}
-
-Obviously, for this thread implementation to be usefull it must run some user code. Several other threading interfaces use a function-pointer representation as the interface of threads (for example \Csharp~\cite{Csharp} and Scala~\cite{Scala}). However, this proposal considers that statically tying a \code{main} routine to a thread superseeds this approach. Since the \code{main} routine is already a special routine in \CFA (where the program begins), it is possible naturally extend the semantics using overloading to declare mains for different threads (the normal main being the main of the initial thread). As such the \code{main} routine of a thread can be defined as
-\begin{cfacode}
-	thread foo {};
-
-	void main(foo* this) {
-		sout | "Hello World!" | endl;
-	}
-\end{cfacode}
-
-In this example, threads of type \code{foo} will start there execution in the \code{void main(foo*)} routine which in this case prints \code{"Hello World!"}. While this proposoal encourages this approach which enforces strongly type programming, users may prefer to use the routine based thread semantics for the sake of simplicity. With these semantics it is trivial to write a thread type that takes a function pointer as parameter and executes it on its stack asynchronously
-\begin{cfacode}
-	typedef void (*voidFunc)(void);
-
-	thread FuncRunner {
-		voidFunc func;
-	};
-
-	//ctor
-	void ?{}(FuncRunner* this, voidFunc inFunc) {
-		func = inFunc;
-	}
-
-	//main
-	void main(FuncRunner* this) {
-		this->func();
-	}
-\end{cfacode}
-
-An advantage of the overloading approach to main is to clearly highlight where and what memory is required to pass parameters and return values to/from a thread.
-
-Of course for threads to be useful, it must be possible to start and stop threads and wait for them to complete execution. While using an \acrshort{api} such as \code{fork} and \code{join} is relatively common in the literature, such an interface is unnecessary. Indeed, the simplest approach is to use \acrshort{raii} principles and have threads \code{fork} once the constructor has completed and \code{join} before the destructor runs.
-\begin{cfacode}
-thread World;
-
-void main(thread World* this) {
-	sout | "World!" | endl;
-}
-
-void main() {
-	World w;
-	//Thread run forks here
-
-	//Printing "Hello " and "World!" will be run concurrently
-	sout | "Hello " | endl;
-
-	//Implicit join at end of scope
-}
-\end{cfacode}
-
-This semantic has several advantages over explicit semantics typesafety is guaranteed, a thread is always started and stopped exaclty once and users cannot make any progamming errors. However, one of the apparent drawbacks of this system is that threads now always form a lattice, that is they are always destroyed in opposite order of construction. While this seems like a significant limitation, existing \CFA semantics can solve this problem. Indeed, using dynamic allocation to create threads will naturally let threads outlive the scope in which the thread was created much like dynamically allocating memory will let objects outlive the scope in which thy were created
-
-\begin{cfacode}
-	thread MyThread {
-		//...
-	};
-
-	//main
-	void main(MyThread* this) {
-		//...
-	}
-
-	void foo() {
-		MyThread* long_lived;
-		{
-			MyThread short_lived;
-			//Start a thread at the beginning of the scope
-
-			DoStuff();
-
-			//create another thread that will outlive the thread in this scope
-			long_lived = new MyThread;
-
-			//Wait for the thread short_lived to finish
-		}
-		DoMoreStuff();
-
-		//Now wait for the short_lived to finish
-		delete long_lived;
-	}
-\end{cfacode}
-
-Another advantage of this semantic is that it naturally scale to multiple threads meaning basic synchronisation is very simple
-
-\begin{cfacode}
-	thread MyThread {
-		//...
-	};
-
-	//main
-	void main(MyThread* this) {
-		//...
-	}
-
-	void foo() {
-		MyThread thrds[10];
-		//Start 10 threads at the beginning of the scope
-
-		DoStuff();
-
-		//Wait for the 10 threads to finish
-	}
-\end{cfacode}
Index: c/proposals/concurrency/text/concurrency.tex
===================================================================
--- doc/proposals/concurrency/text/concurrency.tex	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ 	(revision )
@@ -1,803 +1,0 @@
-% ======================================================================
-% ======================================================================
-\chapter{Concurrency}
-% ======================================================================
-% ======================================================================
-Several tool can be used to solve concurrency challenges. Since many of these challenges appear with the use of mutable shared-state, some languages and libraries simply disallow mutable shared-state (Erlang~\cite{Erlang}, Haskell~\cite{Haskell}, Akka (Scala)~\cite{Akka}). In these paradigms, interaction among concurrent objects relies on message passing~\cite{Thoth,Harmony,V-Kernel} or other paradigms that closely relate to networking concepts (channels\cit for example). However, in languages that use routine calls as their core abstraction-mechanism, these approaches force a clear distinction between concurrent and non-concurrent paradigms (i.e., message passing versus routine call). This distinction in turn means that, in order to be effective, programmers need to learn two sets of designs patterns. This distinction can be hidden away in library code, effective use of the librairy still has to take both paradigms into account. Approaches based on shared memory are more closely related to non-concurrent paradigms since they often rely on basic constructs like routine calls and shared objects. At a lower level, non-concurrent paradigms are often implemented as locks and atomic operations. Many such mechanisms have been proposed, including semaphores~\cite{Dijkstra68b} and path expressions~\cite{Campbell74}. However, for productivity reasons it is desireable to have a higher-level construct be the core concurrency paradigm~\cite{HPP:Study}. An approach that is worth mentionning because it is gaining in popularity is transactionnal memory~\cite{Dice10}[Check citation]. While this approach is even pursued by system languages like \CC\cit, the performance and feature set is currently too restrictive to add such a paradigm to a language like C or \CC\cit, which is why it was rejected as the core paradigm for concurrency in \CFA. One of the most natural, elegant, and efficient mechanisms for synchronization and communication, especially for shared memory systems, is the \emph{monitor}. Monitors were first proposed by Brinch Hansen~\cite{Hansen73} and later described and extended by C.A.R.~Hoare~\cite{Hoare74}. Many programming languages---e.g., Concurrent Pascal~\cite{ConcurrentPascal}, Mesa~\cite{Mesa}, Modula~\cite{Modula-2}, Turing~\cite{Turing:old}, Modula-3~\cite{Modula-3}, NeWS~\cite{NeWS}, Emerald~\cite{Emerald}, \uC~\cite{Buhr92a} and Java~\cite{Java}---provide monitors as explicit language constructs. In addition, operating-system kernels and device drivers have a monitor-like structure, although they often use lower-level primitives such as semaphores or locks to simulate monitors. For these reasons, this project proposes monitors as the core concurrency-construct.
-
-\section{Basics}
-The basic features that concurrency tools neet to offer is support for mutual-exclusion and synchronisation. Mutual-exclusion is the concept that only a fixed number of threads can access a critical section at any given time, where a critical section is the group of instructions on an associated portion of data that requires the limited access. On the other hand, synchronization enforces relative ordering of execution and synchronization tools are used to guarantee that event \textit{X} always happens before \textit{Y}.
-
-\subsection{Mutual-Exclusion}
-As mentionned above, mutual-exclusion is the guarantee that only a fix number of threads can enter a critical section at once. However, many solution exists for mutual exclusion which vary in terms of performance, flexibility and ease of use. Methods range from low level locks, which are fast and flexible but require significant attention to be correct, to  higher level mutual-exclusion methods, which sacrifice some performance in order to improve ease of use. Often by either guaranteeing some problems cannot occur (e.g. being deadlock free) or by offering a more explicit coupling between data and corresponding critical section. For example, the \CC \code{std::atomic<T>} which offer an easy way to express mutual-exclusion on a restricted set of features (.e.g: reading/writing large types atomically). Another challenge with low level locks is composability. Locks are said to not be composable because it takes careful organising for multiple locks to be used and once while preventing deadlocks. Easing composability is another feature higher-level mutual-exclusion mechanisms often offer.
-
-\subsection{Synchronization}
-As for mutual-exclusion, low level synchronisation primitive often offer great performance and good flexibility at the cost of ease of use. Again, higher-level mechanism often simplify usage by adding better coupling between synchronization and data, for example message passing, or offering simple solution to otherwise involved challenges. An example of this is barging. As mentionned above synchronization can be expressed as guaranteeing that event \textit{X} always happens before \textit{Y}. Most of the time synchronisation happens around a critical section, where threads most acquire said critical section in a certain order. However, it may also be desired to be able to guarantee that event \textit{Z} does not occur between \textit{X} and \textit{Y}. This is called barging, where event \textit{X} tries to effect event \textit{Y} but anoter thread races to grab the critical section and emits \textit{Z} before \textit{Y}. Preventing or detecting barging is an involved challenge with low-level locks, which can be made much easier by higher-level constructs.
-
-% ======================================================================
-% ======================================================================
-\section{Monitors}
-% ======================================================================
-% ======================================================================
-A monitor is a set of routines that ensure mutual exclusion when accessing shared state. This concept is generally associated with Object-Oriented Languages like Java~\cite{Java} or \uC~\cite{uC++book} but does not strictly require OOP semantics. The only requirements is the ability to declare a handle to a shared object and a set of routines that act on it :
-\begin{cfacode}
-	typedef /*some monitor type*/ monitor;
-	int f(monitor & m);
-
-	int main() {
-		monitor m;  //Handle m
-		f(m);       //Routine using handle
-	}
-\end{cfacode}
-
-% ======================================================================
-% ======================================================================
-\subsection{Call semantics} \label{call}
-% ======================================================================
-% ======================================================================
-The above monitor example displays some of the intrinsic characteristics. Indeed, it is necessary to use pass-by-reference over pass-by-value for monitor routines. This semantics is important because at their core, monitors are implicit mutual-exclusion objects (locks), and these objects cannot be copied. Therefore, monitors are implicitly non-copyable.
-
-Another aspect to consider is when a monitor acquires its mutual exclusion. For example, a monitor may need to be passed through multiple helper routines that do not acquire the monitor mutual-exclusion on entry. Pass through can be both generic helper routines (\code{swap}, \code{sort}, etc.) or specific helper routines like the following to implement an atomic counter :
-
-\begin{cfacode}
-	monitor counter_t { /*...see section $\ref{data}$...*/ };
-
-	void ?{}(counter_t & nomutex this); //constructor
-	size_t ++?(counter_t & mutex this); //increment
-
-	//need for mutex is platform dependent here
-	void ?{}(size_t * this, counter_t & mutex cnt); //conversion
-\end{cfacode}
-
-Here, the constructor(\code{?\{\}}) uses the \code{nomutex} keyword to signify that it does not acquire the monitor mutual-exclusion when constructing. This semantics is because an object not yet constructed should never be shared and therefore does not require mutual exclusion. The prefix increment operator uses \code{mutex} to protect the incrementing process from race conditions. Finally, there is a conversion operator from \code{counter_t} to \code{size_t}. This conversion may or may not require the \code{mutex} keyword depending on whether or not reading an \code{size_t} is an atomic operation.
-
-Having both \code{mutex} and \code{nomutex} keywords could be argued to be redundant based on the meaning of a routine having neither of these keywords. For example, given a routine without qualifiers \code{void foo(counter_t & this)} then it is reasonable that it should default to the safest option \code{mutex}. On the other hand, the option of having routine \code{void foo(counter_t & this)} mean \code{nomutex} is unsafe by default and may easily cause subtle errors. In fact \code{nomutex} is the "normal" parameter behaviour, with the \code{nomutex} keyword effectively stating explicitly that "this routine is not special". Another alternative is to make having exactly one of these keywords mandatory, which would provide the same semantics but without the ambiguity of supporting routines neither keyword. Mandatory keywords would also have the added benefit of being self-documented but at the cost of extra typing. While there are several benefits to mandatory keywords, they do bring a few challenges. Mandatory keywords in \CFA would imply that the compiler must know without a doubt wheter or not a parameter is a monitor or not. Since \CFA relies heavily on traits as an abstraction mechanism, the distinction between a type that is a monitor and a type that looks like a monitor can become blurred. For this reason, \CFA only has the \code{mutex} keyword.
-
-
-The next semantic decision is to establish when \code{mutex} may be used as a type qualifier. Consider the following declarations:
-\begin{cfacode}
-int f1(monitor & mutex m);
-int f2(const monitor & mutex m);
-int f3(monitor ** mutex m);
-int f4(monitor *[] mutex m);
-int f5(graph(monitor*) & mutex m);
-\end{cfacode}
-The problem is to indentify which object(s) should be acquired. Furthermore, each object needs to be acquired only once. In the case of simple routines like \code{f1} and \code{f2} it is easy to identify an exhaustive list of objects to acquire on entry. Adding indirections (\code{f3}) still allows the compiler and programmer to indentify which object is acquired. However, adding in arrays (\code{f4}) makes it much harder. Array lengths are not necessarily known in C, and even then making sure objects are only acquired once becomes none-trivial. This can be extended to absurd limits like \code{f5}, which uses a graph of monitors. To keep everyone as sane as possible~\cite{Chicken}, this projects imposes the requirement that a routine may only acquire one monitor per parameter and it must be the type of the parameter with one level of indirection (ignoring potential qualifiers). Also note that while routine \code{f3} can be supported, meaning that monitor \code{**m} is be acquired, passing an array to this routine would be type safe and yet result in undefined behavior because only the first element of the array is acquired. This is specially true for non-copyable objects like monitors, where an array of pointers is simplest way to express a group of monitors. However, this ambiguity is part of the C type-system with respects to arrays. For this reason, \code{mutex} is disallowed in the context where arrays may be passed:
-
-\begin{cfacode}
-int f1(monitor & mutex m);   //Okay : recommanded case
-int f2(monitor * mutex m);   //Okay : could be an array but probably not
-int f3(monitor [] mutex m);  //Not Okay : Array of unkown length
-int f4(monitor ** mutex m);  //Not Okay : Could be an array
-int f5(monitor *[] mutex m); //Not Okay : Array of unkown length
-\end{cfacode}
-
-Unlike object-oriented monitors, where calling a mutex member \emph{implicitly} acquires mutual-exclusion, \CFA uses an explicit mechanism to acquire mutual-exclusion. A consequence of this approach is that it extends naturally to multi-monitor calls.
-\begin{cfacode}
-int f(MonitorA & mutex a, MonitorB & mutex b);
-
-MonitorA a;
-MonitorB b;
-f(a,b);
-\end{cfacode}
-The capacity to acquire multiple locks before entering a critical section is called \emph{\gls{group-acquire}}. In practice, writing multi-locking routines that do not lead to deadlocks is tricky. Having language support for such a feature is therefore a significant asset for \CFA. In the case presented above, \CFA guarantees that the order of aquisition is consistent across calls to routines using the same monitors as arguments. However, since \CFA monitors use multi-acquisition locks, users can effectively force the acquiring order. For example, notice which routines use \code{mutex}/\code{nomutex} and how this affects aquiring order:
-\begin{cfacode}
-	void foo(A & mutex a, B & mutex b) { //acquire a & b
-		...
-	}
-
-	void bar(A & mutex a, B & /*nomutex*/ b) { //acquire a
-		... foo(a, b); ... //acquire b
-	}
-
-	void baz(A & /*nomutex*/ a, B & mutex b) { //acquire b
-		... foo(a, b); ... //acquire a
-	}
-\end{cfacode}
-The multi-acquisition monitor lock allows a monitor lock to be acquired by both \code{bar} or \code{baz} and acquired again in \code{foo}. In the calls to \code{bar} and \code{baz} the monitors are acquired in opposite order. 
-
-However, such use leads the lock acquiring order problem. In the example above, the user uses implicit ordering in the case of function \code{foo} but explicit ordering in the case of \code{bar} and \code{baz}. This subtle mistake means that calling these routines concurrently may lead to deadlock and is therefore undefined behavior. As shown on several occasion\cit, solving this problem requires:
-\begin{enumerate}
-	\item Dynamically tracking of the monitor-call order.
-	\item Implement rollback semantics.
-\end{enumerate}
-While the first requirement is already a significant constraint on the system, implementing a general rollback semantics in a C-like language is prohibitively complex \cit. In \CFA, users simply need to be carefull when acquiring multiple monitors at the same time.
-
-Finally, for convenience, monitors support multiple acquiring, that is acquiring a monitor while already holding it does not cause a deadlock. It simply increments an internal counter which is then used to release the monitor after the number of acquires and releases match up. This is particularly usefull when monitor routines use other monitor routines as helpers or for recursions. For example:
-\begin{cfacode}
-monitor bank {
-	int money;
-	log_t usr_log;
-};
-
-void deposit( bank & mutex b, int deposit ) {
-	b.money += deposit;
-	b.usr_log | "Adding" | deposit | endl;
-}
-
-void transfer( bank & mutex mybank, bank & mutex yourbank, int me2you) {
-	deposit( mybank, -me2you );
-	deposit( yourbank, me2you );
-}
-\end{cfacode}
-
-% ======================================================================
-% ======================================================================
-\subsection{Data semantics} \label{data}
-% ======================================================================
-% ======================================================================
-Once the call semantics are established, the next step is to establish data semantics. Indeed, until now a monitor is used simply as a generic handle but in most cases monitors contain shared data. This data should be intrinsic to the monitor declaration to prevent any accidental use of data without its appropriate protection. For example, here is a complete version of the counter showed in section \ref{call}:
-\begin{cfacode}
-monitor counter_t {
-	int value;
-};
-
-void ?{}(counter_t & this) {
-	this.cnt = 0;
-}
-
-int ?++(counter_t & mutex this) {
-	return ++this.value;
-}
-
-//need for mutex is platform dependent here
-void ?{}(int * this, counter_t & mutex cnt) {
-	*this = (int)cnt;
-}
-\end{cfacode}
-
-This counter is used as follows:
-\begin{center}
-\begin{tabular}{c @{\hskip 0.35in} c @{\hskip 0.35in} c}
-\begin{cfacode}
-//shared counter
-counter_t cnt1, cnt2;
-
-//multiple threads access counter
-thread 1 : cnt1++; cnt2++;
-thread 2 : cnt1++; cnt2++;
-thread 3 : cnt1++; cnt2++;
-	...
-thread N : cnt1++; cnt2++;
-\end{cfacode}
-\end{tabular}
-\end{center}
-Notice how the counter is used without any explicit synchronisation and yet supports thread-safe semantics for both reading and writting. 
-
-% ======================================================================
-% ======================================================================
-\subsection{Implementation Details: Interaction with polymorphism}
-% ======================================================================
-% ======================================================================
-Depending on the choice of semantics for when monitor locks are acquired, interaction between monitors and \CFA's concept of polymorphism can be complex to support. However, it is shown that entry-point locking solves most of the issues.
-
-First of all, interaction between \code{otype} polymorphism and monitors is impossible since monitors do not support copying. Therefore, the main question is how to support \code{dtype} polymorphism. Since a monitor's main purpose is to ensure mutual exclusion when accessing shared data, this implies that mutual exclusion is only required for routines that do in fact access shared data. However, since \code{dtype} polymorphism always handles incomplete types (by definition), no \code{dtype} polymorphic routine can access shared data since the data requires knowledge about the type. Therefore, the only concern when combining \code{dtype} polymorphism and monitors is to protect access to routines. 
-
-Before looking into complex control flow, it is important to present the difference between the two acquiring options : \gls{callsite-locking} and \gls{entry-point-locking}, i.e. acquiring the monitors before making a mutex routine call or as the first instruction of the mutex routine call. For example:
-\begin{center}
-\setlength\tabcolsep{1.5pt}
-\begin{tabular}{|c|c|c|}
-Code & \gls{callsite-locking} & \gls{entry-point-locking} \\
-\CFA & pseudo-code & pseudo-code \\
-\hline
-\begin{cfacode}[tabsize=3]
-void foo(monitor& mutex a){
-
-
-
-	//Do Work
-	//...
-
-}
-
-void main() {
-	monitor a;
-
-
-
-	foo(a);
-
-}
-\end{cfacode} & \begin{pseudo}[tabsize=3]
-foo(& a) {
-
-
-
-	//Do Work
-	//...
-
-}
-
-main() {
-	monitor a;
-	//calling routine
-	//handles concurrency
-	acquire(a);
-	foo(a);
-	release(a);
-}
-\end{pseudo} & \begin{pseudo}[tabsize=3]
-foo(& a) {
-	//called routine
-	//handles concurrency
-	acquire(a);
-	//Do Work
-	//...
-	release(a);
-}
-
-main() {
-	monitor a;
-
-
-
-	foo(a);
-
-}
-\end{pseudo}
-\end{tabular}
-\end{center}
-
-\Gls{callsite-locking} is inefficient, since any \code{dtype} routine may have to obtain some lock before calling a routine, depending on whether or not the type passed is a monitor. However, with \gls{entry-point-locking} calling a monitor routine becomes exactly the same as calling it from anywhere else. Note that the \code{mutex} keyword relies on the resolver rather than another form of language, which mean that in cases where a generic monitor routine is actually desired, writing a mutex routine is possible with the proper trait. This is possible because monitors are designed in terms a trait. For example:
-\begin{cfacode}
-//Incorrect
-//T is not a monitor
-forall(dtype T)
-void foo(T * mutex t); 
-
-//Correct
-//this function only works on monitors 
-//(any monitor)
-forall(dtype T | is_monitor(T))
-void bar(T * mutex t)); 
-\end{cfacode}
-
-
-% ======================================================================
-% ======================================================================
-\section{Internal scheduling} \label{insched}
-% ======================================================================
-% ======================================================================
-In addition to mutual exclusion, the monitors at the core of \CFA's concurrency can also be used to achieve synchronisation. With monitors, this is generally achieved with internal or external scheduling as in\cit. Since internal scheduling of single monitors is mostly a solved problem, this proposal concentraits on extending internal scheduling to multiple monitors at once. Indeed, like the \gls{group-acquire} semantics, internal scheduling extends to multiple monitors at once in a way that is natural to the user but requires additional complexity on the implementation side.
-
-First, Here is a simple example of such a technique:
-
-\begin{cfacode}
-	monitor A {
-		condition e;
-	}
-
-	void foo(A & mutex a) {
-		...
-		// Wait for cooperation from bar()
-		wait(a.e);
-		...
-	}
-
-	void bar(A & mutex a) {
-		// Provide cooperation for foo()
-		...
-		// Unblock foo at scope exit
-		signal(a.e);
-	}
-\end{cfacode}
-
-There are two details to note here. First, there \code{signal} is a delayed operation, it only unblocks the waiting thread when it reaches the end of the critical section. This is needed to respect mutual-exclusion. Second, in \CFA, \code{condition} have no particular need to be stored inside a monitor, beyond any software engineering reasons. Here routine \code{foo} waits for the \code{signal} from \code{bar} before making further progress, effectively ensuring a basic ordering. 
-
-An important aspect to take into account here is that \CFA does not allow barging, which means that once function \code{bar} releases the monitor, foo is guaranteed to resume immediately after (unless some other thread waited on the same condition). This guarantees offers the benefit of not having to loop arount waits in order to guarantee that a condition is still met. The main reason \CFA offers this guarantee is that users can easily introduce barging if it becomes a necessity but adding barging prevention or barging avoidance is more involved without language support. Supporting barging prevention as well as extending internal scheduling to multiple monitors is the main source of complexity in the design of \CFA concurrency.
-
-% ======================================================================
-% ======================================================================
-\subsection{Internal Scheduling - multi monitor}
-% ======================================================================
-% ======================================================================
-It easier to understand the problem of multi-monitor scheduling using a series of pseudo-code. Note that for simplicity in the following snippets of pseudo-code, waiting and signalling is done using an implicit condition variable, like Java built-in monitors.
-
-\begin{multicols}{2}
-thread 1
-\begin{pseudo}
-acquire A
-	wait A
-release A
-\end{pseudo}
-
-\columnbreak
-
-thread 2
-\begin{pseudo}
-acquire A
-	signal A
-release A
-\end{pseudo}
-\end{multicols}
-
-The previous example shows the simple case of having two threads (one for each column) and a single monitor A. One thread acquires before waiting (atomically blocking and releasing A) and the other acquires before signalling. There is an important thing to note here, both \code{wait} and \code{signal} must be called with the proper monitor(s) already acquired. This restriction is hidden on the user side in \uC, as it is a logical requirement for barging prevention. 
-
-A direct extension of the previous example is the \gls{group-acquire} version:
-
-\begin{multicols}{2}
-\begin{pseudo}
-acquire A & B
-	wait A & B
-release A & B
-\end{pseudo}
-
-\columnbreak
-
-\begin{pseudo}
-acquire A & B
-	signal A & B
-release A & B
-\end{pseudo}
-\end{multicols}
-
-This version uses \gls{group-acquire} (denoted using the \& symbol), but the presence of multiple monitors does not add a particularly new meaning. Synchronization happens between the two threads in exactly the same way and order. The only difference is that mutual exclusion covers more monitors. On the implementation side, handling multiple monitors does add a degree of complexity as the next few examples demonstrate.
-
-While deadlock issues can occur when nesting monitors, these issues are only a symptom of the fact that locks, and by extension monitors, are not perfectly composable. However, for monitors as for locks, it is possible to write a program using nesting without encountering any problems if nested is done correctly. For example, the next pseudo-code snippet acquires monitors A then B before waiting while only acquiring B when signalling, effectively avoiding the nested monitor problem.
-
-\begin{multicols}{2}
-\begin{pseudo}
-acquire A
-	acquire B
-		wait B
-	release B
-release A
-\end{pseudo}
-
-\columnbreak
-
-\begin{pseudo}
-
-acquire B
-	signal B
-release B
-
-\end{pseudo}
-\end{multicols}
-
-The next example is where \gls{group-acquire} adds a significant layer of complexity to the internal signalling semantics.
-
-\begin{multicols}{2}
-Waiting thread
-\begin{pseudo}[numbers=left]
-acquire A
-	// Code Section 1
-	acquire A & B
-		// Code Section 2
-		wait A & B
-		// Code Section 3
-	release A & B
-	// Code Section 4
-release A
-\end{pseudo}
-
-\columnbreak
-
-Signalling thread
-\begin{pseudo}[numbers=left, firstnumber=10]
-acquire A
-	// Code Section 5
-	acquire A & B
-		// Code Section 6
-		signal A & B
-		// Code Section 7
-	release A & B
-	// Code Section 8
-release A
-\end{pseudo}
-\end{multicols}
-\begin{center}
-Listing 1
-\end{center}
-
-It is particularly important to pay attention to code sections 8 and 3, which are where the existing semantics of internal scheduling need to be extended for multiple monitors. The root of the problem is that \gls{group-acquire} is used in a context where one of the monitors is already acquired and is why it is important to define the behaviour of the previous pseudo-code. When the signaller thread reaches the location where it should "release A \& B" (line 17), it must actually transfer ownership of monitor B to the waiting thread. This ownership trasnfer is required in order to prevent barging. Since the signalling thread still needs the monitor A, simply waking up the waiting thread is not an option because it would violate mutual exclusion. We are therefore left with three options:
-
-\subsubsection{Delaying signals}
-The first more obvious solution to solve the problem of multi-monitor scheduling is to keep ownership of all locks until the last lock is ready to be transferred. It can be argued that that moment is the correct time to transfer ownership when the last lock is no longer needed is what fits most closely to the behaviour of single monitor scheduling. This solution has the main benefit of transferring ownership of groups of monitors, which simplifies the semantics from mutiple objects to a single groupd of object. Effectively making the existing single monitor semantic viable by simply changing monitors to monitor collections.
-\begin{multicols}{2}
-Waiter
-\begin{pseudo}[numbers=left]
-acquire A
-	acquire A & B
-		wait A & B
-	release A & B
-release A
-\end{pseudo}
-
-\columnbreak
-
-Signaller
-\begin{pseudo}[numbers=left, firstnumber=6]
-acquire A
-	acquire A & B
-		signal A & B
-	release A & B
-	//Secretly keep B here
-release A
-//Wakeup waiter and transfer A & B
-\end{pseudo}
-\end{multicols}
-However, this solution can become much more complicated depending on what is executed while secretly holding B. Indeed, nothing prevents a user from signalling monitor A on a different condition variable:
-\newpage
-\begin{multicols}{2}
-Thread 1
-\begin{pseudo}[numbers=left, firstnumber=1]
-acquire A
-	acquire A & B
-		wait A & B
-	release A & B
-release A
-\end{pseudo}
-
-Thread 2
-\begin{pseudo}[numbers=left, firstnumber=6]
-acquire A
-	wait A
-release A
-\end{pseudo}
-
-\columnbreak
-
-Thread 3
-\begin{pseudo}[numbers=left, firstnumber=10]
-acquire A
-	acquire A & B
-		signal A & B
-	release A & B
-	//Secretly keep B here
-	signal A
-release A
-//Wakeup thread 1 or 2?
-//Who wakes up the other thread?
-\end{pseudo}
-\end{multicols}
-
-The goal in this solution is to avoid the need to transfer ownership of a subset of the condition monitors. However, this goal is unreacheable in the previous example. Depending on the order of signals (line 12 and 15) two cases can happen. Note that ordering is not determined by a race condition but by whether signalled threads are enqueued in FIFO or FILO order. However, regardless of the answer, users can move line 15 before line 11 and get the reverse effect.
-
-\paragraph{Case 1: thread 1 will go first.} In this case, the problem is that monitor A needs to be passed to thread 2 when thread 1 is done with it. 
-\paragraph{Case 2: thread 2 will go first.} In this case, the problem is that monitor B needs to be passed to thread 1. This can be done directly or using thread 2 as an intermediate. 
-\\
-
-In both cases however, the threads need to be able to distinguish on a per monitor basis which ones need to be released and which ones need to be transferred. Which means monitors cannot be handled as a single homogenous group.
-
-\subsubsection{Dependency graphs}
-In the Listing 1 pseudo-code, there is a solution which would statisfy both barging prevention and mutual exclusion. If ownership of both monitors is transferred to the waiter when the signaller releases A and then the waiter transfers back ownership of A when it releases it then the problem is solved. Dynamically finding the correct order is therefore the second possible solution. The problem it encounters is that it effectively boils down to resolving a dependency graph of ownership requirements. Here even the simplest of code snippets requires two transfers and it seems to increase in a manner closer to polynomial. For example the following code which is just a direct extension to three monitors requires at least three ownership transfer and has multiple solutions: 
-
-\begin{multicols}{2}
-\begin{pseudo}
-acquire A
-	acquire B
-		acquire C
-			wait A & B & C
-		release C
-	release B
-release A
-\end{pseudo}
-
-\columnbreak
-
-\begin{pseudo}
-acquire A
-	acquire B
-		acquire C
-			signal A & B & C
-		release C
-	release B
-release A
-\end{pseudo}
-\end{multicols}
-Resolving dependency graph being a complex and expensive endeavour, this solution is not the preffered one.
-
-\subsubsection{Partial signalling}
-Finally, the solution that was chosen for \CFA is to use partial signalling. Consider the following case:
-
-\begin{multicols}{2}
-\begin{pseudo}[numbers=left]
-acquire A
-	acquire A & B
-		wait A & B
-	release A & B
-release A
-\end{pseudo}
-
-\columnbreak
-
-\begin{pseudo}[numbers=left, firstnumber=6]
-acquire A
-	acquire A & B
-		signal A & B
-	release A & B
-	// ... More code
-release A
-\end{pseudo}
-\end{multicols}
-
-The partial signalling solution transfers ownership of monitor B at lines 10 but does not wake the waiting thread since it is still using monitor A. Only when it reaches line 11 does it actually wakeup the waiting thread. This solution has the benefit that complexity is encapsulated in to only two actions, passing monitors to the next owner when they should be release and conditionnaly waking threads if all conditions are met. Contrary to the other solutions, this solution quickly hits an upper bound on complexity of implementation.
-
-% ======================================================================
-% ======================================================================
-\subsection{Signalling: Now or Later}
-% ======================================================================
-% ======================================================================
-An important note is that, until now, signalling a monitor was a delayed operation. The ownership of the monitor is transferred only when the monitor would have otherwise been released, not at the point of the \code{signal} statement. However, in some cases, it may be more convenient for users to immediately transfer ownership to the thread that is waiting for cooperation. This is achieved using the \code{signal_block} routine\footnote{name to be discussed}.
-
-For example here is an example highlighting the difference in behaviour:
-\begin{center}
-\begin{tabular}{|c|c|}
-\code{signal} & \code{signal_block} \\
-\hline
-\begin{cfacode}
-monitor M { int val; };
-
-void foo(M & mutex m ) {
-	m.val++;
-	sout| "Foo:" | m.val |endl;
-
-	wait( c );
-
-	m.val++;
-	sout| "Foo:" | m.val |endl;
-}
-
-void bar(M & mutex m ) {
-	m.val++;
-	sout| "Bar:" | m.val |endl;
-
-	signal( c );
-
-	m.val++;
-	sout| "Bar:" | m.val |endl;
-}
-\end{cfacode}&\begin{cfacode}
-monitor M { int val; };
-
-void foo(M & mutex m ) {
-	m.val++;
-	sout| "Foo:" | m.val |endl;
-
-	wait( c );
-
-	m.val++;
-	sout| "Foo:" | m.val |endl;
-}
-
-void bar(M & mutex m ) {
-	m.val++;
-	sout| "Bar:" | m.val |endl;
-
-	signal_block( c );
-
-	m.val++;
-	sout| "Bar:" | m.val |endl;
-}
-\end{cfacode}
-\end{tabular}
-\end{center}
-Assuming that \code{val} is initialized at 0, that each routine are called from seperate thread and that \code{foo} is always called first. The previous code would yield the following output:
-
-\begin{center}
-\begin{tabular}{|c|c|}
-\code{signal} & \code{signal_block} \\
-\hline
-\begin{pseudo}
-Foo: 0
-Bar: 1
-Bar: 2
-Foo: 3
-\end{pseudo}&\begin{pseudo}
-Foo: 0
-Bar: 1
-Foo: 2
-Bar: 3
-\end{pseudo}
-\end{tabular}
-\end{center}
-
-As mentionned, \code{signal} only transfers ownership once the current critical section exits, resulting in the second "Bar" line to be printed before the second "Foo" line. On the other hand, \code{signal_block} immediately transfers ownership to \code{bar}, causing an inversion of output. Obviously this means that \code{signal_block} is a blocking call, which will only be resumed once the signalled function exits the critical section.
-
-% ======================================================================
-% ======================================================================
-\subsection{Internal scheduling: Implementation} \label{insched-impl}
-% ======================================================================
-% ======================================================================
-\TODO
-
-
-% ======================================================================
-% ======================================================================
-\section{External scheduling} \label{extsched}
-% ======================================================================
-% ======================================================================
-An alternative to internal scheduling is to use external scheduling.
-\begin{center}
-\begin{tabular}{|c|c|}
-Internal Scheduling & External Scheduling \\
-\hline
-\begin{ucppcode}
-_Monitor Semaphore {
-	condition c;
-	bool inUse;
-public:
-	void P() { 
-		if(inUse) wait(c); 
-		inUse = true;
-	}
-	void V() { 
-		inUse = false;		
-		signal(c); 
-	}
-}
-\end{ucppcode}&\begin{ucppcode}
-_Monitor Semaphore {
-
-	bool inUse;
-public:
-	void P() { 
-		if(inUse) _Accept(V); 
-		inUse = true;
-	}
-	void g() { 
-		inUse = false;
-
-	}
-}
-\end{ucppcode}
-\end{tabular}
-\end{center}
-This method is more constrained and explicit, which may help users tone down the undeterministic nature of concurrency. Indeed, as the following examples demonstrates, external scheduling allows users to wait for events from other threads without the concern of unrelated events occuring. External scheduling can generally be done either in terms of control flow (e.g. \uC) or in terms of data (e.g. Go). Of course, both of these paradigms have their own strenghts and weaknesses but for this project control flow semantics where chosen to stay consistent with the rest of the languages semantics. Two challenges specific to \CFA arise when trying to add external scheduling with loose object definitions and multi-monitor routines. The following example shows a simple use \code{accept} versus \code{wait}/\code{signal} and its advantages.
-
-In the case of internal scheduling, the call to \code{wait} only guarantees that \code{g} is the last routine to access the monitor. This entails that the routine \code{f} may have acquired mutual exclusion several times while routine \code{h} was waiting. On the other hand, external scheduling guarantees that while routine \code{h} was waiting, no routine other than \code{g} could acquire the monitor.
-
-% ======================================================================
-% ======================================================================
-\subsection{Loose object definitions}
-% ======================================================================
-% ======================================================================
-In \uC, monitor declarations include an exhaustive list of monitor operations. Since \CFA is not object oriented it becomes both more difficult to implement but also less clear for the user:
-
-\begin{cfacode}
-	monitor A {};
-
-	void f(A & mutex a);
-	void g(A & mutex a) { accept(f); }
-\end{cfacode}
-
-However, external scheduling is an example where implementation constraints become visible from the interface. Indeed, since there is no hard limit to the number of threads trying to acquire a monitor concurrently, performance is a significant concern. Here is the pseudo code for the entering phase of a monitor:
-
-\begin{center}
-\begin{tabular}{l}
-\begin{pseudo}
-	if monitor is free
-		enter
-	elif monitor accepts me
-		enter
-	else
-		block
-\end{pseudo}
-\end{tabular}
-\end{center}
-
-For the \pscode{monitor is free} condition it is easy to implement a check that can evaluate the condition in a few instruction. However, a fast check for \pscode{monitor accepts me} is much harder to implement depending on the constraints put on the monitors. Indeed, monitors are often expressed as an entry queue and some acceptor queue as in the following figure:
-
-\begin{center}
-{\resizebox{0.4\textwidth}{!}{\input{monitor}}}
-\end{center}
-
-There are other alternatives to these pictures but in the case of this picture implementing a fast accept check is relatively easy. Indeed simply updating a bitmask when the acceptor queue changes is enough to have a check that executes in a single instruction, even with a fairly large number (e.g. 128) of mutex members. However, this relies on the fact that all the acceptable routines are declared with the monitor type. For OO languages this does not compromise much since monitors already have an exhaustive list of member routines. However, for \CFA this is not the case; routines can be added to a type anywhere after its declaration. Its important to note that the bitmask approach does not actually require an exhaustive list of routines, but it requires a dense unique ordering of routines with an upper-bound and that ordering must be consistent across translation units.
-The alternative would be to have a picture more like this one:
-
-\begin{center}
-{\resizebox{0.4\textwidth}{!}{\input{ext_monitor}}}
-\end{center}
-
-Not storing the queues inside the monitor means that the storage can vary between routines, allowing for more flexibility and extensions. Storing an array of function-pointers would solve the issue of uniquely identifying acceptable routines. However, the single instruction bitmask compare has been replaced by dereferencing a pointer followed by a linear search. Furthermore, supporting nested external scheduling may now require additionnal searches on calls to accept to check if a routine is already queued in.
-
-At this point we must make a decision between flexibility and performance. Many design decisions in \CFA achieve both flexibility and performance, for example polymorphic routines add significant flexibility but inlining them means the optimizer can easily remove any runtime cost. Here however, the cost of flexibility cannot be trivially removed.
-
-In either cases here are a few alternatives for the different syntaxes this syntax : \\
-\begin{center}
-{\renewcommand{\arraystretch}{1.5}
-\begin{tabular}[t]{l @{\hskip 0.35in} l}
-\hline
-\multicolumn{2}{ c }{\code{accept} on type}\\
-\hline
-Alternative 1 & Alternative 2 \\
-\begin{lstlisting}
-mutex struct A
-accept( void f(A & mutex a) )
-{};
-\end{lstlisting} &\begin{lstlisting}
-mutex struct A {}
-accept( void f(A & mutex a) );
-
-\end{lstlisting} \\
-Alternative 3 & Alternative 4 \\
-\begin{lstlisting}
-mutex struct A {
-	accept( void f(A & mutex a) )
-};
-
-\end{lstlisting} &\begin{lstlisting}
-mutex struct A {
-	accept :
-		void f(A & mutex a) );
-};
-\end{lstlisting}\\
-\hline
-\multicolumn{2}{ c }{\code{accept} on routine}\\
-\hline
-\begin{lstlisting}
-mutex struct A {};
-
-void f(A & mutex a)
-
-accept( void f(A & mutex a) )
-void g(A & mutex a) {
-	/*...*/
-}
-\end{lstlisting}&\\
-\end{tabular}
-}
-\end{center}
-
-Another aspect to consider is what happens if multiple overloads of the same routine are used. For the time being it is assumed that multiple overloads of the same routine should be scheduled regardless of the overload used. However, this could easily be extended in the future.
-
-% ======================================================================
-% ======================================================================
-\subsection{Multi-monitor scheduling}
-% ======================================================================
-% ======================================================================
-
-External scheduling, like internal scheduling, becomes orders of magnitude more complex when we start introducing multi-monitor syntax. Even in the simplest possible case some new semantics need to be established:
-\begin{cfacode}
-	accept( void f(mutex struct A & mutex this))
-	mutex struct A {};
-
-	mutex struct B {};
-
-	void g(A & mutex a, B & mutex b) {
-		accept(f); //ambiguous, which monitor
-	}
-\end{cfacode}
-
-The obvious solution is to specify the correct monitor as follows:
-
-\begin{cfacode}
-	accept( void f(mutex struct A & mutex this))
-	mutex struct A {};
-
-	mutex struct B {};
-
-	void g(A & mutex a, B & mutex b) {
-		accept( b, f );
-	}
-\end{cfacode}
-
-This is unambiguous. Both locks will be acquired and kept, when routine \code{f} is called the lock for monitor \code{a} will be temporarily transferred from \code{g} to \code{f} (while \code{g} still holds lock \code{b}). This behavior can be extended to multi-monitor accept statment as follows.
-
-\begin{cfacode}
-	accept( void f(mutex struct A & mutex, mutex struct A & mutex))
-	mutex struct A {};
-
-	mutex struct B {};
-
-	void g(A & mutex a, B & mutex b) {
-		accept( b, a, f);
-	}
-\end{cfacode}
-
-Note that the set of monitors passed to the \code{accept} statement must be entirely contained in the set of monitor already acquired in the routine. \code{accept} used in any other context is Undefined Behaviour.
-
-% ======================================================================
-% ======================================================================
-\subsection{Implementation Details: External scheduling queues}
-% ======================================================================
-% ======================================================================
-To support multi-monitor external scheduling means that some kind of entry-queues must be used that is aware of both monitors. However, acceptable routines must be aware of the entry queues which means they must be stored inside at least one of the monitors that will be acquired. This in turn adds the requirement a systematic algorithm of disambiguating which queue is relavant regardless of user ordering. The proposed algorithm is to fall back on monitors lock ordering and specify that the monitor that is acquired first is the lock with the relevant entry queue. This assumes that the lock acquiring order is static for the lifetime of all concerned objects but that is a reasonable constraint. This algorithm choice has two consequences, the entry queue of the highest priority monitor is no longer a true FIFO queue and the queue of the lowest priority monitor is both required and probably unused. The queue can no longer be a FIFO queue because instead of simply containing the waiting threads in order arrival, they also contain the second mutex. Therefore, another thread with the same highest priority monitor but a different lowest priority monitor may arrive first but enter the critical section after a thread with the correct pairing. Secondly, since it may not be known at compile time which monitor will be the lowest priority monitor, every monitor needs to have the correct queues even though it is probable that half the multi-monitor queues will go unused for the entire duration of the program.
-
-% ======================================================================
-% ======================================================================
-\section{Other concurrency tools}
-% ======================================================================
-% ======================================================================
-% \TODO
Index: c/proposals/concurrency/text/intro.tex
===================================================================
--- doc/proposals/concurrency/text/intro.tex	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ 	(revision )
@@ -1,7 +1,0 @@
-% ======================================================================
-\chapter{Introduction}
-% ======================================================================
-
-This proposal provides a minimal concurrency API that is simple, efficient and can be reused to build higher-level features. The simplest possible concurrency core is a thread and a lock but this low-level approach is hard to master. An easier approach for users is to support higher-level constructs as the basis of the concurrency in \CFA. Indeed, for highly productive parallel programming, high-level approaches are much more popular~\cite{HPP:Study}. Examples are task based, message passing and implicit threading.
-
-There are actually two problems that need to be solved in the design of concurrency for a programming language: which concurrency tools are available to the users and which parallelism tools are available. While these two concepts are often seen together, they are in fact distinct concepts that require different sorts of tools~\cite{Buhr05a}. Concurrency tools need to handle mutual exclusion and synchronization, while parallelism tools are about performance, cost and resource utilization.
Index: c/proposals/concurrency/text/parallelism.tex
===================================================================
--- doc/proposals/concurrency/text/parallelism.tex	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ 	(revision )
@@ -1,117 +1,0 @@
-% ######     #    ######     #    #       #       ####### #       ###  #####  #     #
-% #     #   # #   #     #   # #   #       #       #       #        #  #     # ##   ##
-% #     #  #   #  #     #  #   #  #       #       #       #        #  #       # # # #
-% ######  #     # ######  #     # #       #       #####   #        #   #####  #  #  #
-% #       ####### #   #   ####### #       #       #       #        #        # #     #
-% #       #     # #    #  #     # #       #       #       #        #  #     # #     #
-% #       #     # #     # #     # ####### ####### ####### ####### ###  #####  #     #
-\chapter{Parallelism}
-Historically, computer performance was about processor speeds and instructions count. However, with heat dissipation being a direct consequence of speed increase, parallelism has become the new source for increased performance~\cite{Sutter05, Sutter05b}. In this decade, it is not longer reasonnable to create a high-performance application without caring about parallelism. Indeed, parallelism is an important aspect of performance and more specifically throughput and hardware utilization. The lowest-level approach of parallelism is to use \glspl{kthread} in combination with semantics like \code{fork}, \code{join}, etc. However, since these have significant costs and limitations, \glspl{kthread} are now mostly used as an implementation tool rather than a user oriented one. There are several alternatives to solve these issues that all have strengths and weaknesses. While there are many variations of the presented paradigms, most of these variations do not actually change the guarantees or the semantics, they simply move costs in order to achieve better performance for certain workloads.
-
-\section{Paradigm}
-\subsection{User-level threads}
-A direct improvement on the \gls{kthread} approach is to use \glspl{uthread}. These threads offer most of the same features that the operating system already provide but can be used on a much larger scale. This approach is the most powerfull solution as it allows all the features of multi-threading, while removing several of the more expensives costs of using kernel threads. The down side is that almost none of the low-level threading problems are hidden, users still have to think about data races, deadlocks and synchronization issues. These issues can be somewhat alleviated by a concurrency toolkit with strong garantees but the parallelism toolkit offers very little to reduce complexity in itself.
-
-Examples of languages that support \glspl{uthread} are Erlang~\cite{Erlang} and \uC~\cite{uC++book}.
-
-\subsection{Fibers : user-level threads without preemption}
-A popular varient of \glspl{uthread} is what is often reffered to as \glspl{fiber}. However, \glspl{fiber} do not present meaningful semantical differences with \glspl{uthread}. Advocates of \glspl{fiber} list their high performance and ease of implementation as majors strenghts of \glspl{fiber} but the performance difference between \glspl{uthread} and \glspl{fiber} is controversial and the ease of implementation, while true, is a weak argument in the context of language design. Therefore this proposal largely ignore fibers.
-
-An example of a language that uses fibers is Go~\cite{Go}
-
-\subsection{Jobs and thread pools}
-The approach on the opposite end of the spectrum is to base parallelism on \glspl{pool}. Indeed, \glspl{pool} offer limited flexibility but at the benefit of a simpler user interface. In \gls{pool} based systems, users express parallelism as units of work and a dependency graph (either explicit or implicit) that tie them together. This approach means users need not worry about concurrency but significantly limits the interaction that can occur among jobs. Indeed, any \gls{job} that blocks also blocks the underlying worker, which effectively means the CPU utilization, and therefore throughput, suffers noticeably. It can be argued that a solution to this problem is to use more workers than available cores. However, unless the number of jobs and the number of workers are comparable, having a significant amount of blocked jobs always results in idles cores.
-
-The gold standard of this implementation is Intel's TBB library~\cite{TBB}.
-
-\subsection{Paradigm performance}
-While the choice between the three paradigms listed above may have significant performance implication, it is difficult to pindown the performance implications of chosing a model at the language level. Indeed, in many situations one of these paradigms may show better performance but it all strongly depends on the workload. Having a large amount of mostly independent units of work to execute almost guarantess that the \gls{pool} based system has the best performance thanks to the lower memory overhead. However, interactions between jobs can easily exacerbate contention. User-level threads allow fine-grain context switching, which results in better resource utilisation, but context switches will be more expansive and the extra control means users need to tweak more variables to get the desired performance. Furthermore, if the units of uninterrupted work are large enough the paradigm choice is largely amorticised by the actual work done.
-
-\newpage
-\TODO
-\subsection{The \protect\CFA\ Kernel : Processors, Clusters and Threads}\label{kernel}
-
-
-\subsection{Paradigms}\label{cfaparadigms}
-Given these building blocks we can then reproduce the all three of the popular paradigms. Indeed, we get \glspl{uthread} as the default paradigm in \CFA. However, disabling \glspl{preemption} on the \gls{cfacluster} means \glspl{cfathread} effectively become \glspl{fiber}. Since several \glspl{cfacluster} with different scheduling policy can coexist in the same application, this allows \glspl{fiber} and \glspl{uthread} to coexist in the runtime of an application.
-
-% \subsection{High-level options}\label{tasks}
-%
-% \subsubsection{Thread interface}
-% constructors destructors
-% 	initializer lists
-% monitors
-%
-% \subsubsection{Futures}
-%
-% \subsubsection{Implicit threading}
-% Finally, simpler applications can benefit greatly from having implicit parallelism. That is, parallelism that does not rely on the user to write concurrency. This type of parallelism can be achieved both at the language level and at the system level.
-%
-% \begin{center}
-% \begin{tabular}[t]{|c|c|c|}
-% Sequential & System Parallel & Language Parallel \\
-% \begin{lstlisting}
-% void big_sum(int* a, int* b,
-% 		 int* out,
-% 		 size_t length)
-% {
-% 	for(int i = 0; i < length; ++i ) {
-% 		out[i] = a[i] + b[i];
-% 	}
-% }
-%
-%
-%
-%
-%
-% int* a[10000];
-% int* b[10000];
-% int* c[10000];
-% //... fill in a and b ...
-% big_sum(a, b, c, 10000);
-% \end{lstlisting} &\begin{lstlisting}
-% void big_sum(int* a, int* b,
-% 		 int* out,
-% 		 size_t length)
-% {
-% 	range ar(a, a + length);
-% 	range br(b, b + length);
-% 	range or(out, out + length);
-% 	parfor( ai, bi, oi,
-% 	[](int* ai, int* bi, int* oi) {
-% 		oi = ai + bi;
-% 	});
-% }
-%
-% int* a[10000];
-% int* b[10000];
-% int* c[10000];
-% //... fill in a and b ...
-% big_sum(a, b, c, 10000);
-% \end{lstlisting}&\begin{lstlisting}
-% void big_sum(int* a, int* b,
-% 		 int* out,
-% 		 size_t length)
-% {
-% 	for (ai, bi, oi) in (a, b, out) {
-% 		oi = ai + bi;
-% 	}
-% }
-%
-%
-%
-%
-%
-% int* a[10000];
-% int* b[10000];
-% int* c[10000];
-% //... fill in a and b ...
-% big_sum(a, b, c, 10000);
-% \end{lstlisting}
-% \end{tabular}
-% \end{center}
-%
-% \subsection{Machine setup}\label{machine}
-% Threads are all good and well but wee still some OS support to fully utilize available hardware.
-%
-% \textbf{\large{Work in progress...}} Do wee need something beyond specifying the number of kernel threads?
Index: c/proposals/concurrency/thesis.tex
===================================================================
--- doc/proposals/concurrency/thesis.tex	(revision 4a3685479ce3ea742a9282c31d31ce031849e49c)
+++ 	(revision )
@@ -1,122 +1,0 @@
-% requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
-
-% inline code ©...© (copyright symbol) emacs: C-q M-)
-% red highlighting ®...® (registered trademark symbol) emacs: C-q M-.
-% blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_
-% green highlighting ¢...¢ (cent symbol) emacs: C-q M-"
-% LaTex escape §...§ (section symbol) emacs: C-q M-'
-% keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
-% math escape $...$ (dollar symbol)
-
-\documentclass[letterpaper,12pt,titlepage,oneside,final]{book}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-% Latex packages used in the document.
-\usepackage[T1]{fontenc}					% allow Latin1 (extended ASCII) characters
-\usepackage{textcomp}
-\usepackage[latin1]{inputenc}
-\usepackage{fullpage,times,comment}
-\usepackage{epic,eepic}
-\usepackage{upquote}						% switch curled `'" to straight
-\usepackage{dirtytalk}
-\usepackage{calc}
-\usepackage{xspace}
-\usepackage{graphicx}
-\usepackage{tabularx}
-\usepackage{multicol}
-\usepackage[acronym]{glossaries}
-\usepackage{varioref}	
-\usepackage{listings}						% format program code
-\usepackage[flushmargin]{footmisc}				% support label/reference in footnote
-\usepackage{latexsym}						% \Box glyph
-\usepackage{mathptmx}						% better math font with "times"
-\usepackage[usenames]{color}
-\usepackage[pagewise]{lineno}
-\usepackage{fancyhdr}
-\renewcommand{\linenumberfont}{\scriptsize\sffamily}
-\input{style}							% bespoke macros used in the document
-\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
-\usepackage{breakurl}
-
-\usepackage{tikz}
-\def\checkmark{\tikz\fill[scale=0.4](0,.35) -- (.25,0) -- (1,.7) -- (.25,.15) -- cycle;}
-
-\renewcommand{\UrlFont}{\small\sf}
-
-\setlength{\topmargin}{-0.45in}				% move running title into header
-\setlength{\headsep}{0.25in}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-% Names used in the document.
-
-\newcommand{\Version}{1.0.0}
-\newcommand{\CS}{C\raisebox{-0.9ex}{\large$^\sharp$}\xspace}
-
-\newcommand{\Textbf}[2][red]{{\color{#1}{\textbf{#2}}}}
-\newcommand{\Emph}[2][red]{{\color{#1}\textbf{\emph{#2}}}}
-\newcommand{\R}[1]{\Textbf{#1}}
-\newcommand{\B}[1]{{\Textbf[blue]{#1}}}
-\newcommand{\G}[1]{{\Textbf[OliveGreen]{#1}}}
-\newcommand{\uC}{$\mu$\CC}
-\newcommand{\cit}{\textsuperscript{[Citation Needed]}\xspace}
-\newcommand{\TODO}{{\Textbf{TODO}}}
-
-\input{glossary}
-
-\newsavebox{\LstBox}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\setcounter{secnumdepth}{3}                           % number subsubsections
-\setcounter{tocdepth}{3}                              % subsubsections in table of contents
-% \linenumbers                                       	% comment out to turn off line numbering
-\makeindex
-\pagestyle{fancy}
-\fancyhf{}
-\cfoot{\thepage}
-\rfoot{v\input{build/version}}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{document}
-% \linenumbers
-
-\title{Concurrency in \CFA}
-\author{Thierry Delisle \\
-School of Computer Science, University of Waterloo, \\ Waterloo, Ontario, Canada
-}
-
-\maketitle
-
-\tableofcontents
-
-\input{intro}
-
-\input{basics}
-
-\input{concurrency}
-
-\input{parallelism}
-
-\chapter{Putting it all together}
-
-\chapter{Conclusion}
-
-\chapter{Future work}
-Concurrency and parallelism is still a very active field that strongly benefits from hardware advances. As such certain features that aren't necessarily mature enough in their current state could become relevant in the lifetime of \CFA.
-\subsection{Transactions}
-
-\section*{Acknowledgements}
-
-\clearpage
-\printglossary[type=\acronymtype]
-\printglossary
-
-\clearpage
-\bibliographystyle{plain}
-\bibliography{cw92,distSharedMem,lfp92,mlw92,parallel,parallelIO,partheory,pl,pldi92,ps,realtime,techreportsPAB,visual,local}
-
-
-\end{document}
Index: doc/proposals/concurrency/version
===================================================================
--- doc/proposals/concurrency/version	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
+++ doc/proposals/concurrency/version	(revision 4c5b9725b156e55f8bbc1fd3c67caef88980552f)
@@ -0,0 +1,1 @@
+0.8.2
