Changeset aac7197 for doc/papers


Ignore:
Timestamp:
Mar 22, 2018, 11:44:36 PM (4 years ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, with_gc
Children:
84832d87
Parents:
6ecc079
Message:

working copy, no latin-1 characters

Location:
doc/papers/concurrency
Files:
4 edited

Legend:

Unmodified
Added
Removed
  • doc/papers/concurrency/Makefile

    r6ecc079 raac7197  
    44Figures = figures
    55Macros = AMA/AMA-stix/ama
    6 TeXLIB = .:style:annex:../../LaTeXmacros:${Macros}:${Build}:../../bibliography:
     6TeXLIB = .:annex:../../LaTeXmacros:${Macros}:${Build}:../../bibliography:
    77LaTeX  = TEXINPUTS=${TeXLIB} && export TEXINPUTS && latex -halt-on-error -output-directory=${Build}
    88BibTeX = BIBINPUTS=${TeXLIB} && export BIBINPUTS && bibtex
  • doc/papers/concurrency/Paper.tex

    r6ecc079 raac7197  
    1 % inline code ©...© (copyright symbol) emacs: C-q M-)
    2 % red highlighting ®...® (registered trademark symbol) emacs: C-q M-.
    3 % blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_
    4 % green highlighting ¢...¢ (cent symbol) emacs: C-q M-"
    5 % LaTex escape §...§ (section symbol) emacs: C-q M-'
    6 % keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
    7 % math escape $...$ (dollar symbol)
    8 
    91\documentclass[AMA,STIX1COL]{WileyNJD-v2}
    102
     
    2012
    2113% Latex packages used in the document.
    22 
    23 \usepackage[T1]{fontenc}                                        % allow Latin1 (extended ASCII) characters
    24 \usepackage{textcomp}
    25 \usepackage[latin1]{inputenc}
    26 
    2714\usepackage{epic,eepic}
    2815\usepackage{xspace}
     
    3421\usepackage{siunitx}
    3522\sisetup{ binary-units=true }
    36 \input{style}                                                           % bespoke macros used in the document
     23%\input{style}                                                          % bespoke macros used in the document
    3724
    3825\hypersetup{breaklinks=true}
     
    5138% Names used in the document.
    5239
    53 \newcommand{\CS}{C\raisebox{-0.9ex}{\large$^\sharp$}\xspace}
     40\newcommand{\CFAIcon}{\textsf{C}\raisebox{\depth}{\rotatebox{180}{\textsf{A}}}\xspace} % Cforall symbolic name
     41\newcommand{\CFA}{\protect\CFAIcon}             % safe for section/caption
     42\newcommand{\CFL}{\textrm{Cforall}\xspace}      % Cforall symbolic name
     43\newcommand{\Celeven}{\textrm{C11}\xspace}      % C11 symbolic name
     44\newcommand{\CC}{\textrm{C}\kern-.1em\hbox{+\kern-.25em+}\xspace} % C++ symbolic name
     45\newcommand{\CCeleven}{\textrm{C}\kern-.1em\hbox{+\kern-.25em+}11\xspace} % C++11 symbolic name
     46\newcommand{\CCfourteen}{\textrm{C}\kern-.1em\hbox{+\kern-.25em+}14\xspace} % C++14 symbolic name
     47\newcommand{\CCseventeen}{\textrm{C}\kern-.1em\hbox{+\kern-.25em+}17\xspace} % C++17 symbolic name
     48\newcommand{\CCtwenty}{\textrm{C}\kern-.1em\hbox{+\kern-.25em+}20\xspace} % C++20 symbolic name
     49\newcommand{\Csharp}{C\raisebox{-0.7ex}{\Large$^\sharp$}\xspace} % C# symbolic name
     50
     51%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    5452
    5553\newcommand{\Textbf}[2][red]{{\color{#1}{\textbf{#2}}}}
     
    6260\newcommand{\TODO}{{\Textbf{TODO}}}
    6361
    64 
    65 \newsavebox{\LstBox}
    66 
    6762%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     63
     64% Default underscore is too low and wide. Cannot use lstlisting "literate" as replacing underscore
     65% removes it as a variable-name character so keywords in variables are highlighted. MUST APPEAR
     66% AFTER HYPERREF.
     67%\DeclareTextCommandDefault{\textunderscore}{\leavevmode\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}
     68\renewcommand{\textunderscore}{\leavevmode\makebox[1.2ex][c]{\rule{1ex}{0.075ex}}}
     69
     70\makeatletter
     71% parindent is relative, i.e., toggled on/off in environments like itemize, so store the value for
     72% use rather than use \parident directly.
     73\newlength{\parindentlnth}
     74\setlength{\parindentlnth}{\parindent}
     75
     76\newcommand{\LstBasicStyle}[1]{{\lst@basicstyle{\lst@basicstyle{#1}}}}
     77\newcommand{\LstKeywordStyle}[1]{{\lst@basicstyle{\lst@keywordstyle{#1}}}}
     78\newcommand{\LstCommentStyle}[1]{{\lst@basicstyle{\lst@commentstyle{#1}}}}
     79
     80\newlength{\gcolumnposn}                                        % temporary hack because lstlisting does not handle tabs correctly
     81\newlength{\columnposn}
     82\setlength{\gcolumnposn}{3.5in}
     83\setlength{\columnposn}{\gcolumnposn}
     84\newcommand{\C}[2][\@empty]{\ifx#1\@empty\else\global\setlength{\columnposn}{#1}\global\columnposn=\columnposn\fi\hfill\makebox[\textwidth-\columnposn][l]{\lst@basicstyle{\LstCommentStyle{#2}}}}
     85\newcommand{\CRT}{\global\columnposn=\gcolumnposn}
     86
     87% Denote newterms in particular font and index them without particular font and in lowercase, e.g., \newterm{abc}.
     88% The option parameter provides an index term different from the new term, e.g., \newterm[\texttt{abc}]{abc}
     89% The star version does not lowercase the index information, e.g., \newterm*{IBM}.
     90\newcommand{\newtermFontInline}{\emph}
     91\newcommand{\newterm}{\@ifstar\@snewterm\@newterm}
     92\newcommand{\@newterm}[2][\@empty]{\lowercase{\def\temp{#2}}{\newtermFontInline{#2}}\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi}
     93\newcommand{\@snewterm}[2][\@empty]{{\newtermFontInline{#2}}\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi}
     94
     95% Latin abbreviation
     96\newcommand{\abbrevFont}{\textit}                       % set empty for no italics
     97\newcommand{\EG}{\abbrevFont{e}.\abbrevFont{g}.}
     98\newcommand*{\eg}{%
     99        \@ifnextchar{,}{\EG}%
     100                {\@ifnextchar{:}{\EG}%
     101                        {\EG,\xspace}}%
     102}%
     103\newcommand{\IE}{\abbrevFont{i}.\abbrevFont{e}.}
     104\newcommand*{\ie}{%
     105        \@ifnextchar{,}{\IE}%
     106                {\@ifnextchar{:}{\IE}%
     107                        {\IE,\xspace}}%
     108}%
     109\newcommand{\ETC}{\abbrevFont{etc}}
     110\newcommand*{\etc}{%
     111        \@ifnextchar{.}{\ETC}%
     112        {\ETC.\xspace}%
     113}%
     114\newcommand{\ETAL}{\abbrevFont{et}~\abbrevFont{al}}
     115\renewcommand*{\etal}{%
     116        \@ifnextchar{.}{\protect\ETAL}%
     117                {\protect\ETAL.\xspace}%
     118}%
     119\newcommand{\VIZ}{\abbrevFont{viz}}
     120\newcommand*{\viz}{%
     121        \@ifnextchar{.}{\VIZ}%
     122                {\VIZ.\xspace}%
     123}%
     124\makeatother
     125
     126\newenvironment{cquote}{%
     127        \list{}{\lstset{resetmargins=true,aboveskip=0pt,belowskip=0pt}\topsep=3pt\parsep=0pt\leftmargin=\parindentlnth\rightmargin\leftmargin}%
     128        \item\relax
     129}{%
     130        \endlist
     131}% cquote
     132
     133% CFA programming language, based on ANSI C (with some gcc additions)
     134\lstdefinelanguage{CFA}[ANSI]{C}{
     135        morekeywords={
     136                _Alignas, _Alignof, __alignof, __alignof__, asm, __asm, __asm__, _At, __attribute,
     137                __attribute__, auto, _Bool, catch, catchResume, choose, _Complex, __complex, __complex__,
     138                __const, __const__, disable, dtype, enable, exception, __extension__, fallthrough, fallthru,
     139                finally, forall, ftype, _Generic, _Imaginary, inline, __label__, lvalue, _Noreturn, one_t,
     140                otype, restrict, _Static_assert, throw, throwResume, trait, try, ttype, typeof, __typeof,
     141                __typeof__, virtual, with, zero_t},
     142        morekeywords=[2]{
     143                _Atomic, coroutine, is_coroutine, is_monitor, is_thread, monitor, mutex, nomutex, or,
     144                resume, suspend, thread, _Thread_local, waitfor, when, yield},
     145        moredirectives={defined,include_next}%
     146}
     147
     148\lstset{
     149language=CFA,
     150columns=fullflexible,
     151basicstyle=\linespread{0.9}\sf,                                                 % reduce line spacing and use sanserif font
     152stringstyle=\tt,                                                                                % use typewriter font
     153tabsize=5,                                                                                              % N space tabbing
     154xleftmargin=\parindentlnth,                                                             % indent code to paragraph indentation
     155%mathescape=true,                                                                               % LaTeX math escape in CFA code $...$
     156escapechar=\$,                                                                                  % LaTeX escape in CFA code
     157keepspaces=true,                                                                                %
     158showstringspaces=false,                                                                 % do not show spaces with cup
     159showlines=true,                                                                                 % show blank lines at end of code
     160aboveskip=4pt,                                                                                  % spacing above/below code block
     161belowskip=3pt,
     162% replace/adjust listing characters that look bad in sanserif
     163literate={-}{\makebox[1ex][c]{\raisebox{0.4ex}{\rule{0.8ex}{0.1ex}}}}1 {^}{\raisebox{0.6ex}{$\scriptstyle\land\,$}}1
     164        {~}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}}1 % {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1
     165        {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2 {->}{\makebox[1ex][c]{\raisebox{0.5ex}{\rule{0.8ex}{0.075ex}}}\kern-0.2ex{\textgreater}}2,
     166moredelim=**[is][\color{red}]{`}{`},
     167}% lstset
     168
     169% uC++ programming language, based on ANSI C++
     170\lstdefinelanguage{uC++}[ANSI]{C++}{
     171        morekeywords={
     172                _Accept, _AcceptReturn, _AcceptWait, _Actor, _At, _CatchResume, _Cormonitor, _Coroutine, _Disable,
     173                _Else, _Enable, _Event, _Finally, _Monitor, _Mutex, _Nomutex, _PeriodicTask, _RealTimeTask,
     174                _Resume, _Select, _SporadicTask, _Task, _Timeout, _When, _With, _Throw},
     175}
     176\lstdefinelanguage{Golang}{
     177        morekeywords=[1]{package,import,func,type,struct,return,defer,panic,recover,select,var,const,iota,},
     178        morekeywords=[2]{string,uint,uint8,uint16,uint32,uint64,int,int8,int16,int32,int64,
     179                bool,float32,float64,complex64,complex128,byte,rune,uintptr, error,interface},
     180        morekeywords=[3]{map,slice,make,new,nil,len,cap,copy,close,true,false,delete,append,real,imag,complex,chan,},
     181        morekeywords=[4]{for,break,continue,range,goto,switch,case,fallthrough,if,else,default,},
     182        morekeywords=[5]{Println,Printf,Error,},
     183        sensitive=true,
     184        morecomment=[l]{//},
     185        morecomment=[s]{/*}{*/},
     186        morestring=[b]',
     187        morestring=[b]",
     188        morestring=[s]{`}{`},
     189}
     190
     191\lstnewenvironment{cfa}[1][]
     192{\lstset{#1}}
     193{}
     194\lstnewenvironment{C++}[1][]                            % use C++ style
     195{\lstset{language=C++,moredelim=**[is][\protect\color{red}]{`}{`},#1}\lstset{#1}}
     196{}
     197\lstnewenvironment{uC++}[1][]
     198{\lstset{#1}}
     199{}
     200\lstnewenvironment{Go}[1][]
     201{\lstset{#1}}
     202{}
     203
     204% inline code @...@
     205\lstMakeShortInline@%
     206
    68207
    69208\title{\texorpdfstring{Concurrency in \protect\CFA}{Concurrency in Cforall}}
     
    81220\abstract[Summary]{
    82221\CFA is a modern, polymorphic, \emph{non-object-oriented} extension of the C programming language.
    83 This paper discusses the design of the concurrency and parallelism features in \CFA, and the concurrent runtime-system that supports them.
     222This paper discusses the design of the concurrency and parallelism features in \CFA, and the concurrent runtime-system.
    84223These features are created from scratch as ISO C lacks concurrency, relying largely on pthreads.
    85224Coroutines and lightweight (user) threads are introduced into the language.
     
    87226A unique contribution is allowing multiple monitors to be safely acquired simultaneously.
    88227All features respect the expectations of C programmers, while being fully integrate with the \CFA polymorphic type-system and other language features.
    89 Finally, experimental results are presented to validate several of the new features with other concurrent programming-languages.
     228Finally, experimental results are presented to compare the performance of the new features with similar mechanisms in other concurrent programming-languages.
    90229}%
    91230
     
    104243% ======================================================================
    105244
    106 This paper provides a minimal concurrency \textbf{api} that is simple, efficient and can be reused to build higher-level features.
    107 The simplest possible concurrency system is a thread and a lock but this low-level approach is hard to master.
    108 An easier approach for users is to support higher-level constructs as the basis of concurrency.
    109 Indeed, for highly productive concurrent programming, high-level approaches are much more popular~\cite{HPP:Study}.
    110 Examples are task based, message passing and implicit threading.
    111 The high-level approach and its minimal \textbf{api} are tested in a dialect of C, called \CFA.
    112 Furthermore, the proposed \textbf{api} doubles as an early definition of the \CFA language and library.
    113 This paper also provides an implementation of the concurrency library for \CFA as well as all the required language features added to the source-to-source translator.
    114 
    115 There are actually two problems that need to be solved in the design of concurrency for a programming language: which concurrency and which parallelism tools are available to the programmer.
     245This paper provides a minimal concurrency \newterm{API} that is simple, efficient and can be used to build other concurrency features.
     246While the simplest concurrency system is a thread and a lock, this low-level approach is hard to master.
     247An easier approach for programmers is to support higher-level constructs as the basis of concurrency.
     248Indeed, for highly productive concurrent programming, high-level approaches are much more popular~\cite{Hochstein05}.
     249Examples of high-level approaches are task based~\cite{TBB}, message passing~\cite{Erlang,MPI}, and implicit threading~\cite{OpenMP}.
     250
     251The terminology used in this paper is as follows.
     252A \newterm{thread} is a fundamental unit of execution that runs a sequence of code and requires a stack to maintain state.
     253Multiple simultaneous threads gives rise to \newterm{concurrency}, which requires locking to ensure safe access to shared data.
     254% Correspondingly, concurrency is defined as the concepts and challenges that occur when multiple independent (sharing memory, timing dependencies, etc.) concurrent threads are introduced.
     255\newterm{Locking}, and by extension locks, are defined as a mechanism to prevent progress of threads to provide safety.
     256\newterm{Parallelism} is running multiple threads simultaneously.
     257Parallelism implies \emph{actual} simultaneous execution, where concurrency only requires \emph{apparent} simultaneous execution.
     258As such, parallelism is only observable in differences in performance, which is observed through differences in timing.
     259
     260Hence, there are two problems to be solved in the design of concurrency for a programming language: concurrency and parallelism.
    116261While these two concepts are often combined, they are in fact distinct, requiring different tools~\cite{Buhr05a}.
    117 Concurrency tools need to handle mutual exclusion and synchronization, while parallelism tools are about performance, cost and resource utilization.
    118 
    119 In the context of this paper, a \textbf{thread} is a fundamental unit of execution that runs a sequence of code, generally on a program stack.
    120 Having multiple simultaneous threads gives rise to concurrency and generally requires some kind of locking mechanism to ensure proper execution.
    121 Correspondingly, \textbf{concurrency} is defined as the concepts and challenges that occur when multiple independent (sharing memory, timing dependencies, etc.) concurrent threads are introduced.
    122 Accordingly, \textbf{locking} (and by extension locks) are defined as a mechanism that prevents the progress of certain threads in order to avoid problems due to concurrency.
    123 Finally, in this paper \textbf{parallelism} is distinct from concurrency and is defined as running multiple threads simultaneously.
    124 More precisely, parallelism implies \emph{actual} simultaneous execution as opposed to concurrency which only requires \emph{apparent} simultaneous execution.
    125 As such, parallelism is only observable in the differences in performance or, more generally, differences in timing.
     262Concurrency tools handle mutual exclusion and synchronization, while parallelism tools handle performance, cost and resource utilization.
     263
     264The proposed concurrency API is implemented in a dialect of C, called \CFA.
     265The paper discusses how the language features are added to the \CFA translator with respect to parsing, semantic, and type checking, and the corresponding high-perforamnce runtime-library to implement the concurrency features.
    126266
    127267% ======================================================================
     
    139279Interestingly, while \CFA is not an object-oriented language, lacking the concept of a receiver (e.g., {\tt this}), it does have some notion of objects\footnote{C defines the term objects as : ``region of data storage in the execution environment, the contents of which can represent
    140280values''~\cite[3.15]{C11}}, most importantly construction and destruction of objects.
    141 Most of the following code examples can be found on the \CFA website~\cite{www-cfa}.
    142 
    143 % ======================================================================
     281Most of the following code examples can be found on the \CFA website~\cite{Cforall}.
     282
     283
    144284\subsection{References}
    145285
    146286Like \CC, \CFA introduces rebind-able references providing multiple dereferencing as an alternative to pointers.
    147287In regards to concurrency, the semantic difference between pointers and references are not particularly relevant, but since this document uses mostly references, here is a quick overview of the semantics:
    148 \begin{cfacode}
     288\begin{cfa}
    149289int x, *p1 = &x, **p2 = &p1, ***p3 = &p2,
    150290        &r1 = x,    &&r2 = r1,   &&&r3 = r2;
    151 ***p3 = 3;                                                      //change x
    152 r3    = 3;                                                      //change x, ***r3
    153 **p3  = ...;                                            //change p1
    154 *p3   = ...;                                            //change p2
    155 int y, z, & ar[3] = {x, y, z};          //initialize array of references
    156 typeof( ar[1]) p;                                       //is int, referenced object type
    157 typeof(&ar[1]) q;                                       //is int &, reference type
    158 sizeof( ar[1]) == sizeof(int);          //is true, referenced object size
    159 sizeof(&ar[1]) == sizeof(int *);        //is true, reference size
    160 \end{cfacode}
     291***p3 = 3;                                                      $\C{// change x}$
     292r3    = 3;                                                      $\C{// change x, ***r3}$
     293**p3  = ...;                                            $\C{// change p1}$
     294*p3   = ...;                                            $\C{// change p2}$
     295int y, z, & ar[3] = {x, y, z};          $\C{// initialize array of references}$
     296typeof( ar[1]) p;                                       $\C{// is int, referenced object type}$
     297typeof(&ar[1]) q;                                       $\C{// is int \&, reference type}$
     298sizeof( ar[1]) == sizeof(int);          $\C{// is true, referenced object size}$
     299sizeof(&ar[1]) == sizeof(int *);        $\C{// is true, reference size}$
     300\end{cfa}
    161301The important take away from this code example is that a reference offers a handle to an object, much like a pointer, but which is automatically dereferenced for convenience.
    162302
     
    167307As well, \CFA uses the return type as part of the selection criteria, as in Ada~\cite{Ada}.
    168308For routines with multiple parameters and returns, the selection is complex.
    169 \begin{cfacode}
    170 //selection based on type and number of parameters
    171 void f(void);                   //(1)
    172 void f(char);                   //(2)
    173 void f(int, double);    //(3)
    174 f();                                    //select (1)
    175 f('a');                                 //select (2)
    176 f(3, 5.2);                              //select (3)
    177 
    178 //selection based on  type and number of returns
    179 char   f(int);                  //(1)
    180 double f(int);                  //(2)
    181 char   c = f(3);                //select (1)
    182 double d = f(4);                //select (2)
    183 \end{cfacode}
     309\begin{cfa}
     310// selection based on type and number of parameters
     311void f(void);                   $\C{// (1)}$
     312void f(char);                   $\C{// (2)}$
     313void f(int, double);    $\C{// (3)}$
     314f();                                    $\C{// select (1)}$
     315f('a');                                 $\C{// select (2)}$
     316f(3, 5.2);                              $\C{// select (3)}$
     317
     318// selection based on  type and number of returns
     319char   f(int);                  $\C{// (1)}$
     320double f(int);                  $\C{// (2)}$
     321char   c = f(3);                $\C{// select (1)}$
     322double d = f(4);                $\C{// select (2)}$
     323\end{cfa}
    184324This feature is particularly important for concurrency since the runtime system relies on creating different types to represent concurrency objects.
    185325Therefore, overloading is necessary to prevent the need for long prefixes and other naming conventions that prevent name clashes.
    186 As seen in section \ref{basics}, routine \code{main} is an example that benefits from overloading.
     326As seen in section \ref{basics}, routine @main@ is an example that benefits from overloading.
    187327
    188328% ======================================================================
     
    190330Overloading also extends to operators.
    191331The syntax for denoting operator-overloading is to name a routine with the symbol of the operator and question marks where the arguments of the operation appear, e.g.:
    192 \begin{cfacode}
    193 int ++? (int op);                       //unary prefix increment
    194 int ?++ (int op);                       //unary postfix increment
    195 int ?+? (int op1, int op2);             //binary plus
    196 int ?<=?(int op1, int op2);             //binary less than
    197 int ?=? (int & op1, int op2);           //binary assignment
    198 int ?+=?(int & op1, int op2);           //binary plus-assignment
     332\begin{cfa}
     333int ++? (int op);                       $\C{// unary prefix increment}$
     334int ?++ (int op);                       $\C{// unary postfix increment}$
     335int ?+? (int op1, int op2);             $\C{// binary plus}$
     336int ?<=?(int op1, int op2);             $\C{// binary less than}$
     337int ?=? (int & op1, int op2);           $\C{// binary assignment}$
     338int ?+=?(int & op1, int op2);           $\C{// binary plus-assignment}$
    199339
    200340struct S {int i, j;};
    201 S ?+?(S op1, S op2) {                           //add two structures
     341S ?+?(S op1, S op2) {                           $\C{// add two structures}$
    202342        return (S){op1.i + op2.i, op1.j + op2.j};
    203343}
    204344S s1 = {1, 2}, s2 = {2, 3}, s3;
    205 s3 = s1 + s2;                                           //compute sum: s3 == {2, 5}
    206 \end{cfacode}
     345s3 = s1 + s2;                                           $\C{// compute sum: s3 == {2, 5}}$
     346\end{cfa}
    207347While concurrency does not use operator overloading directly, this feature is more important as an introduction for the syntax of constructors.
    208348
     
    211351Object lifetime is often a challenge in concurrency. \CFA uses the approach of giving concurrent meaning to object lifetime as a means of synchronization and/or mutual exclusion.
    212352Since \CFA relies heavily on the lifetime of objects, constructors and destructors is a core feature required for concurrency and parallelism. \CFA uses the following syntax for constructors and destructors:
    213 \begin{cfacode}
     353\begin{cfa}
    214354struct S {
    215355        size_t size;
    216356        int * ia;
    217357};
    218 void ?{}(S & s, int asize) {    //constructor operator
    219         s.size = asize;                         //initialize fields
     358void ?{}(S & s, int asize) {    $\C{// constructor operator}$
     359        s.size = asize;                         $\C{// initialize fields}$
    220360        s.ia = calloc(size, sizeof(S));
    221361}
    222 void ^?{}(S & s) {                              //destructor operator
    223         free(ia);                                       //de-initialization fields
     362void ^?{}(S & s) {                              $\C{// destructor operator}$
     363        free(ia);                                       $\C{// de-initialization fields}$
    224364}
    225365int main() {
    226         S x = {10}, y = {100};          //implicit calls: ?{}(x, 10), ?{}(y, 100)
    227         ...                                                     //use x and y
    228         ^x{};  ^y{};                            //explicit calls to de-initialize
    229         x{20};  y{200};                         //explicit calls to reinitialize
    230         ...                                                     //reuse x and y
    231 }                                                               //implicit calls: ^?{}(y), ^?{}(x)
    232 \end{cfacode}
     366        S x = {10}, y = {100};          $\C{// implicit calls: ?\{\}(x, 10), ?\{\}(y, 100)}$
     367        ...                                                     $\C{// use x and y}$
     368        ^x{};  ^y{};                            $\C{// explicit calls to de-initialize}$
     369        x{20};  y{200};                         $\C{// explicit calls to reinitialize}$
     370        ...                                                     $\C{// reuse x and y}$
     371}                                                               $\C{// implicit calls: \^?\{\}(y), \^?\{\}(x)}$
     372\end{cfa}
    233373The language guarantees that every object and all their fields are constructed.
    234374Like \CC, construction of an object is automatically done on allocation and destruction of the object is done on deallocation.
    235375Allocation and deallocation can occur on the stack or on the heap.
    236 \begin{cfacode}
     376\begin{cfa}
    237377{
    238         struct S s = {10};      //allocation, call constructor
     378        struct S s = {10};      $\C{// allocation, call constructor}$
    239379        ...
    240 }                                               //deallocation, call destructor
    241 struct S * s = new();   //allocation, call constructor
     380}                                               $\C{// deallocation, call destructor}$
     381struct S * s = new();   $\C{// allocation, call constructor}$
    242382...
    243 delete(s);                              //deallocation, call destructor
    244 \end{cfacode}
    245 Note that like \CC, \CFA introduces \code{new} and \code{delete}, which behave like \code{malloc} and \code{free} in addition to constructing and destructing objects, after calling \code{malloc} and before calling \code{free}, respectively.
     383delete(s);                              $\C{// deallocation, call destructor}$
     384\end{cfa}
     385Note that like \CC, \CFA introduces @new@ and @delete@, which behave like @malloc@ and @free@ in addition to constructing and destructing objects, after calling @malloc@ and before calling @free@, respectively.
    246386
    247387% ======================================================================
     
    249389\label{s:ParametricPolymorphism}
    250390Routines in \CFA can also be reused for multiple types.
    251 This capability is done using the \code{forall} clauses, which allow separately compiled routines to support generic usage over multiple types.
     391This capability is done using the @forall@ clauses, which allow separately compiled routines to support generic usage over multiple types.
    252392For example, the following sum function works for any type that supports construction from 0 and addition:
    253 \begin{cfacode}
    254 //constraint type, 0 and +
     393\begin{cfa}
     394// constraint type, 0 and +
    255395forall(otype T | { void ?{}(T *, zero_t); T ?+?(T, T); })
    256396T sum(T a[ ], size_t size) {
    257         T total = 0;                            //construct T from 0
     397        T total = 0;                            $\C{// construct T from 0}$
    258398        for(size_t i = 0; i < size; i++)
    259                 total = total + a[i];   //select appropriate +
     399                total = total + a[i];   $\C{// select appropriate +}$
    260400        return total;
    261401}
    262402
    263403S sa[5];
    264 int i = sum(sa, 5);                             //use S's 0 construction and +
    265 \end{cfacode}
     404int i = sum(sa, 5);                             $\C{// use S's 0 construction and +}$
     405\end{cfa}
    266406
    267407Since writing constraints on types can become cumbersome for more constrained functions, \CFA also has the concept of traits.
    268408Traits are named collection of constraints that can be used both instead and in addition to regular constraints:
    269 \begin{cfacode}
     409\begin{cfa}
    270410trait summable( otype T ) {
    271         void ?{}(T *, zero_t);          //constructor from 0 literal
    272         T ?+?(T, T);                            //assortment of additions
     411        void ?{}(T *, zero_t);          $\C{// constructor from 0 literal}$
     412        T ?+?(T, T);                            $\C{// assortment of additions}$
    273413        T ?+=?(T *, T);
    274414        T ++?(T *);
    275415        T ?++(T *);
    276416};
    277 forall( otype T | summable(T) ) //use trait
     417forall( otype T | summable(T) ) $\C{// use trait}$
    278418T sum(T a[], size_t size);
    279 \end{cfacode}
    280 
    281 Note that the type use for assertions can be either an \code{otype} or a \code{dtype}.
    282 Types declared as \code{otype} refer to ``complete'' objects, i.e., objects with a size, a default constructor, a copy constructor, a destructor and an assignment operator.
    283 Using \code{dtype,} on the other hand, has none of these assumptions but is extremely restrictive, it only guarantees the object is addressable.
     419\end{cfa}
     420
     421Note that the type use for assertions can be either an @otype@ or a @dtype@.
     422Types declared as @otype@ refer to ``complete'' objects, i.e., objects with a size, a default constructor, a copy constructor, a destructor and an assignment operator.
     423Using @dtype@, on the other hand, has none of these assumptions but is extremely restrictive, it only guarantees the object is addressable.
    284424
    285425% ======================================================================
    286426\subsection{with Clause/Statement}
    287427Since \CFA lacks the concept of a receiver, certain functions end up needing to repeat variable names often.
    288 To remove this inconvenience, \CFA provides the \code{with} statement, which opens an aggregate scope making its fields directly accessible (like Pascal).
    289 \begin{cfacode}
     428To remove this inconvenience, \CFA provides the @with@ statement, which opens an aggregate scope making its fields directly accessible (like Pascal).
     429\begin{cfa}
    290430struct S { int i, j; };
    291 int mem(S & this) with (this)           //with clause
    292         i = 1;                                                  //this->i
    293         j = 2;                                                  //this->j
     431int mem(S & this) with (this)           $\C{// with clause}$
     432        i = 1;                                                  $\C{// this->i}$
     433        j = 2;                                                  $\C{// this->j}$
    294434}
    295435int foo() {
    296436        struct S1 { ... } s1;
    297437        struct S2 { ... } s2;
    298         with (s1)                                               //with statement
     438        with (s1)                                               $\C{// with statement}$
    299439        {
    300                 //access fields of s1 without qualification
    301                 with (s2)                                       //nesting
     440                // access fields of s1 without qualification
     441                with (s2)                                       $\C{// nesting}$
    302442                {
    303                         //access fields of s1 and s2 without qualification
     443                        // access fields of s1 and s2 without qualification
    304444                }
    305445        }
    306         with (s1, s2)                                   //scopes open in parallel
     446        with (s1, s2)                                   $\C{// scopes open in parallel}$
    307447        {
    308                 //access fields of s1 and s2 without qualification
    309         }
    310 }
    311 \end{cfacode}
    312 
    313 For more information on \CFA see \cite{cforall-ug,rob-thesis,www-cfa}.
     448                // access fields of s1 and s2 without qualification
     449        }
     450}
     451\end{cfa}
     452
     453For more information on \CFA see \cite{cforall-ug,Schluntz17,www-cfa}.
    314454
    315455% ======================================================================
     
    339479Optimal performance in concurrent applications is often obtained by having as much non-determinism as correctness allows.
    340480
     481
    341482\section{\protect\CFA's Thread Building Blocks}
     483
    342484One of the important features that are missing in C is threading\footnote{While the C11 standard defines a ``threads.h'' header, it is minimal and defined as optional.
    343485As such, library support for threading is far from widespread.
     
    347489And being a system-level language means programmers expect to choose precisely which features they need and which cost they are willing to pay.
    348490
     491
    349492\section{Coroutines: A Stepping Stone}\label{coroutine}
     493
    350494While the main focus of this proposal is concurrency and parallelism, it is important to address coroutines, which are actually a significant building block of a concurrency system. \textbf{Coroutine}s are generalized routines which have predefined points where execution is suspended and can be resumed at a later time.
    351495Therefore, they need to deal with context switches and other context-management operations.
    352496This proposal includes coroutines both as an intermediate step for the implementation of threads, and a first-class feature of \CFA.
    353497Furthermore, many design challenges of threads are at least partially present in designing coroutines, which makes the design effort that much more relevant.
    354 The core \textbf{api} of coroutines revolves around two features: independent call-stacks and \code{suspend}/\code{resume}.
    355 
    356 \begin{table}
     498The core \textbf{api} of coroutines revolves around two features: independent call-stacks and @suspend@/@resume@.
     499
     500\begin{figure}
    357501\begin{center}
    358 \begin{tabular}{c @{\hskip 0.025in}|@{\hskip 0.025in} c @{\hskip 0.025in}|@{\hskip 0.025in} c}
    359 \begin{ccode}[tabsize=2]
    360 //Using callbacks
     502\begin{tabular}{c|c|c}
     503\begin{cfa}
     504// Using callback
    361505void fibonacci_func(
    362506        int n,
    363         void (*callback)(int)
     507        void (* callback)( int )
    364508) {
    365         int first = 0;
    366         int second = 1;
    367         int next, i;
    368         for(i = 0; i < n; i++)
    369         {
    370                 if(i <= 1)
    371                         next = i;
    372                 else {
    373                         next = f1 + f2;
    374                         f1 = f2;
    375                         f2 = next;
    376                 }
    377                 callback(next);
    378         }
    379 }
    380 
     509        int fn, f1 = 0, f2 = 1;
     510        for ( int i = 0; i < n; i++ ) {
     511                callback( f1 );
     512                fn = f1 + f2;
     513                f1 = f2;  f2 = fn;
     514        }
     515}
    381516int main() {
    382         void print_fib(int n) {
    383                 printf("%d\n", n);
    384         }
    385 
    386         fibonacci_func(
    387                 10, print_fib
    388         );
    389 
    390 
    391 
    392 }
    393 \end{ccode}&\begin{ccode}[tabsize=2]
    394 //Using output array
     517        void print_fib( int n ) {
     518                printf( "%d\n", n );
     519        }
     520        fibonacci_func( 10, print_fib );
     521}
     522
     523\end{cfa}
     524&
     525\begin{cfa}
     526// Using output array
    395527void fibonacci_array(
    396528        int n,
    397         int* array
     529        int * array
    398530) {
    399         int f1 = 0; int f2 = 1;
    400         int next, i;
    401         for(i = 0; i < n; i++)
    402         {
    403                 if(i <= 1)
    404                         next = i;
    405                 else {
    406                         next = f1 + f2;
    407                         f1 = f2;
    408                         f2 = next;
    409                 }
    410                 array[i] = next;
    411         }
    412 }
    413 
    414 
     531        int fn, f1 = 0, f2 = 1;
     532        for ( int i = 0; i < n; i++ ) {
     533                array[i] = f1;
     534                fn = f1 + f2;
     535                f1 = f2;  f2 = fn;
     536        }
     537}
    415538int main() {
    416539        int a[10];
    417 
    418         fibonacci_func(
    419                 10, a
    420         );
    421 
    422         for(int i=0;i<10;i++){
    423                 printf("%d\n", a[i]);
    424         }
    425 
    426 }
    427 \end{ccode}&\begin{ccode}[tabsize=2]
    428 //Using external state
     540        fibonacci_array( 10, a );
     541        for ( int i = 0; i < 10; i++ ) {
     542                printf( "%d\n", a[i] );
     543        }
     544}
     545\end{cfa}
     546&
     547\begin{cfa}
     548// Using external state
    429549typedef struct {
    430550        int f1, f2;
    431551} Iterator_t;
    432 
    433552int fibonacci_state(
    434         Iterator_t* it
     553        Iterator_t * it
    435554) {
    436         int f;
    437         f = it->f1 + it->f2;
    438         it->f2 = it->f1;
    439         it->f1 = max(f,1);
    440         return f;
    441 }
    442 
    443 
    444 
    445 
    446 
    447 
    448 
     555        int ret = it->f1;
     556        int fn = it->f1 + it->f2;
     557        it->f2 = it->f1; it->f1 = fn;
     558        return ret;
     559}
    449560int main() {
    450         Iterator_t it={0,0};
    451 
    452         for(int i=0;i<10;i++){
    453                 printf("%d\n",
    454                         fibonacci_state(
    455                                 &it
    456                         );
    457                 );
    458         }
    459 
    460 }
    461 \end{ccode}
     561        Iterator_t it = { 0, 1 };
     562        for ( int i = 0; i < 10; i++ ) {
     563                printf( "%d\n",
     564                        fibonacci_state( &it ) );
     565        }
     566}
     567\end{cfa}
    462568\end{tabular}
    463569\end{center}
    464 \caption{Different implementations of a Fibonacci sequence generator in C.}
     570\caption{C Fibonacci Implementations}
    465571\label{lst:fibonacci-c}
    466 \end{table}
     572\end{figure}
    467573
    468574A good example of a problem made easier with coroutines is generators, e.g., generating the Fibonacci sequence.
     
    474580Listing \ref{lst:fibonacci-cfa} is an example of a solution to the Fibonacci problem using \CFA coroutines, where the coroutine stack holds sufficient state for the next generation.
    475581This solution has the advantage of having very strong decoupling between how the sequence is generated and how it is used.
    476 Indeed, this version is as easy to use as the \code{fibonacci_state} solution, while the implementation is very similar to the \code{fibonacci_func} example.
     582Indeed, this version is as easy to use as the @fibonacci_state@ solution, while the implementation is very similar to the @fibonacci_func@ example.
    477583
    478584\begin{figure}
    479 \begin{cfacode}[caption={Implementation of Fibonacci using coroutines},label={lst:fibonacci-cfa}]
    480 coroutine Fibonacci {
    481         int fn; //used for communication
    482 };
    483 
    484 void ?{}(Fibonacci& this) { //constructor
    485         this.fn = 0;
    486 }
    487 
    488 //main automatically called on first resume
    489 void main(Fibonacci& this) with (this) {
    490         int fn1, fn2;           //retained between resumes
    491         fn  = 0;
    492         fn1 = fn;
    493         suspend(this);          //return to last resume
    494 
    495         fn  = 1;
    496         fn2 = fn1;
    497         fn1 = fn;
    498         suspend(this);          //return to last resume
    499 
     585\begin{cfa}
     586coroutine Fibonacci { int fn; };                                $\C{// used for communication}$
     587
     588void ?{}( Fibonacci & fib ) with( fib ) { fn = 0; } $\C{// constructor}$
     589
     590void main( Fibonacci & fib ) with( fib ) {              $\C{// main called on first resume}$
     591        int fn1, fn2;                                                           $\C{// retained between resumes}$
     592        fn = 0;  fn1 = fn;                                                      $\C{// 1st case}$
     593        suspend();                                                                      $\C{// restart last resume}$
     594        fn = 1;  fn2 = fn1;  fn1 = fn;                          $\C{// 2nd case}$
     595        suspend();                                                                      $\C{// restart last resume}$
    500596        for ( ;; ) {
    501                 fn  = fn1 + fn2;
    502                 fn2 = fn1;
    503                 fn1 = fn;
    504                 suspend(this);  //return to last resume
    505         }
    506 }
    507 
    508 int next(Fibonacci& this) {
    509         resume(this); //transfer to last suspend
    510         return this.fn;
    511 }
    512 
    513 void main() { //regular program main
     597                fn = fn1 + fn2; fn2 = fn1;  fn1 = fn;   $\C{// general case}$
     598                suspend();                                                              $\C{// restart last resume}$
     599        }
     600}
     601int next( Fibonacci & fib ) with( fib ) {
     602        resume( fib );                                                          $\C{// restart last suspend}$
     603        return fn;
     604}
     605int main() {
    514606        Fibonacci f1, f2;
    515607        for ( int i = 1; i <= 10; i += 1 ) {
     
    517609        }
    518610}
    519 \end{cfacode}
     611\end{cfa}
     612\caption{Coroutine Fibonacci }
     613\label{lst:fibonacci-cfa}
    520614\end{figure}
    521615
    522 Listing \ref{lst:fmt-line} shows the \code{Format} coroutine for restructuring text into groups of character blocks of fixed size.
     616Listing \ref{lst:fmt-line} shows the @Format@ coroutine for restructuring text into groups of character blocks of fixed size.
    523617The example takes advantage of resuming coroutines in the constructor to simplify the code and highlights the idea that interesting control flow can occur in the constructor.
    524618
    525619\begin{figure}
    526 \begin{cfacode}[tabsize=3,caption={Formatting text into lines of 5 blocks of 4 characters.},label={lst:fmt-line}]
    527 //format characters into blocks of 4 and groups of 5 blocks per line
     620\begin{cfa}[tabsize=3,caption={Formatting text into lines of 5 blocks of 4 characters.},label={lst:fmt-line}]
     621// format characters into blocks of 4 and groups of 5 blocks per line
    528622coroutine Format {
    529         char ch;                                                                        //used for communication
    530         int g, b;                                                               //global because used in destructor
     623        char ch;                                                                        // used for communication
     624        int g, b;                                                               // global because used in destructor
    531625};
    532626
    533627void  ?{}(Format& fmt) {
    534         resume( fmt );                                                  //prime (start) coroutine
     628        resume( fmt );                                                  // prime (start) coroutine
    535629}
    536630
     
    541635
    542636void main(Format& fmt) with fmt {
    543         for ( ;; ) {                                                    //for as many characters
    544                 for(g = 0; g < 5; g++) {                //groups of 5 blocks
    545                         for(b = 0; b < 4; fb++) {       //blocks of 4 characters
     637        for ( ;; ) {                                                    // for as many characters
     638                for(g = 0; g < 5; g++) {                // groups of 5 blocks
     639                        for(b = 0; b < 4; fb++) {       // blocks of 4 characters
    546640                                suspend();
    547                                 sout | ch;                                      //print character
     641                                sout | ch;                                      // print character
    548642                        }
    549                         sout | "  ";                                    //print block separator
     643                        sout | "  ";                                    // print block separator
    550644                }
    551                 sout | endl;                                            //print group separator
     645                sout | endl;                                            // print group separator
    552646        }
    553647}
     
    561655        Format fmt;
    562656        char ch;
    563         Eof: for ( ;; ) {                                               //read until end of file
    564                 sin | ch;                                                       //read one character
    565                 if(eof(sin)) break Eof;                 //eof ?
    566                 prt(fmt, ch);                                           //push character for formatting
    567         }
    568 }
    569 \end{cfacode}
     657        Eof: for ( ;; ) {                                               // read until end of file
     658                sin | ch;                                                       // read one character
     659                if(eof(sin)) break Eof;                 // eof ?
     660                prt(fmt, ch);                                           // push character for formatting
     661        }
     662}
     663\end{cfa}
    570664\end{figure}
    571665
     
    582676For example, the following code, while looking benign, can run into undefined behaviour because of thunks:
    583677
    584 \begin{cfacode}
    585 //async: Runs function asynchronously on another thread
     678\begin{cfa}
     679// async: Runs function asynchronously on another thread
    586680forall(otype T)
    587681extern void async(void (*func)(T*), T* obj);
     
    592686void bar() {
    593687        int a;
    594         async(noop, &a); //start thread running noop with argument a
    595 }
    596 \end{cfacode}
     688        async(noop, &a); // start thread running noop with argument a
     689}
     690\end{cfa}
    597691
    598692The generated C code\footnote{Code trimmed down for brevity} creates a local thunk to hold type information:
    599693
    600 \begin{ccode}
     694\begin{cfa}
    601695extern void async(/* omitted */, void (*func)(void*), void* obj);
    602696
     
    612706        async(/* omitted */, ((void (*)(void*))(&_thunk0)), (&a));
    613707}
    614 \end{ccode}
    615 The problem in this example is a storage management issue, the function pointer \code{_thunk0} is only valid until the end of the block, which limits the viable solutions because storing the function pointer for too long causes undefined behaviour; i.e., the stack-based thunk being destroyed before it can be used.
     708\end{cfa}
     709The problem in this example is a storage management issue, the function pointer @_thunk0@ is only valid until the end of the block, which limits the viable solutions because storing the function pointer for too long causes undefined behaviour; i.e., the stack-based thunk being destroyed before it can be used.
    616710This challenge is an extension of challenges that come with second-class routines.
    617711Indeed, GCC nested routines also have the limitation that nested routine cannot be passed outside of the declaration scope.
     
    621715One solution to this challenge is to use composition/containment, where coroutine fields are added to manage the coroutine.
    622716
    623 \begin{cfacode}
     717\begin{cfa}
    624718struct Fibonacci {
    625         int fn; //used for communication
    626         coroutine c; //composition
     719        int fn; // used for communication
     720        coroutine c; // composition
    627721};
    628722
     
    633727void ?{}(Fibonacci& this) {
    634728        this.fn = 0;
    635         //Call constructor to initialize coroutine
     729        // Call constructor to initialize coroutine
    636730        (this.c){myMain};
    637731}
    638 \end{cfacode}
     732\end{cfa}
    639733The downside of this approach is that users need to correctly construct the coroutine handle before using it.
    640734Like any other objects, the user must carefully choose construction order to prevent usage of objects not yet constructed.
     
    645739The next alternative is to use language support to annotate coroutines as follows:
    646740
    647 \begin{cfacode}
     741\begin{cfa}
    648742coroutine Fibonacci {
    649         int fn; //used for communication
     743        int fn; // used for communication
    650744};
    651 \end{cfacode}
    652 The \code{coroutine} keyword means the compiler can find and inject code where needed.
     745\end{cfa}
     746The @coroutine@ keyword means the compiler can find and inject code where needed.
    653747The downside of this approach is that it makes coroutine a special case in the language.
    654748Users wanting to extend coroutines or build their own for various reasons can only do so in ways offered by the language.
     
    661755For coroutines as for threads, many implementations are based on routine pointers or function objects~\cite{Butenhof97, C++14, MS:VisualC++, BoostCoroutines15}.
    662756For example, Boost implements coroutines in terms of four functor object types:
    663 \begin{cfacode}
     757\begin{cfa}
    664758asymmetric_coroutine<>::pull_type
    665759asymmetric_coroutine<>::push_type
    666760symmetric_coroutine<>::call_type
    667761symmetric_coroutine<>::yield_type
    668 \end{cfacode}
     762\end{cfa}
    669763Often, the canonical threading paradigm in languages is based on function pointers, \texttt{pthread} being one of the most well-known examples.
    670764The main problem of this approach is that the thread usage is limited to a generic handle that must otherwise be wrapped in a custom type.
     
    672766
    673767A variation of this would be to use a simple function pointer in the same way \texttt{pthread} does for threads:
    674 \begin{cfacode}
     768\begin{cfa}
    675769void foo( coroutine_t cid, void* arg ) {
    676770        int* value = (int*)arg;
    677         //Coroutine body
     771        // Coroutine body
    678772}
    679773
     
    683777        coroutine_resume( &cid );
    684778}
    685 \end{cfacode}
     779\end{cfa}
    686780This semantics is more common for thread interfaces but coroutines work equally well.
    687781As discussed in section \ref{threads}, this approach is superseded by static approaches in terms of expressivity.
     
    690784
    691785Finally, the underlying approach, which is the one closest to \CFA idioms, is to use trait-based lazy coroutines.
    692 This approach defines a coroutine as anything that satisfies the trait \code{is_coroutine} (as defined below) and is used as a coroutine.
    693 
    694 \begin{cfacode}
     786This approach defines a coroutine as anything that satisfies the trait @is_coroutine@ (as defined below) and is used as a coroutine.
     787
     788\begin{cfa}
    695789trait is_coroutine(dtype T) {
    696790      void main(T& this);
     
    700794forall( dtype T | is_coroutine(T) ) void suspend(T&);
    701795forall( dtype T | is_coroutine(T) ) void resume (T&);
    702 \end{cfacode}
    703 This ensures that an object is not a coroutine until \code{resume} is called on the object.
    704 Correspondingly, any object that is passed to \code{resume} is a coroutine since it must satisfy the \code{is_coroutine} trait to compile.
    705 The advantage of this approach is that users can easily create different types of coroutines, for example, changing the memory layout of a coroutine is trivial when implementing the \code{get_coroutine} routine.
    706 The \CFA keyword \code{coroutine} simply has the effect of implementing the getter and forward declarations required for users to implement the main routine.
     796\end{cfa}
     797This ensures that an object is not a coroutine until @resume@ is called on the object.
     798Correspondingly, any object that is passed to @resume@ is a coroutine since it must satisfy the @is_coroutine@ trait to compile.
     799The advantage of this approach is that users can easily create different types of coroutines, for example, changing the memory layout of a coroutine is trivial when implementing the @get_coroutine@ routine.
     800The \CFA keyword @coroutine@ simply has the effect of implementing the getter and forward declarations required for users to implement the main routine.
    707801
    708802\begin{center}
    709803\begin{tabular}{c c c}
    710 \begin{cfacode}[tabsize=3]
     804\begin{cfa}[tabsize=3]
    711805coroutine MyCoroutine {
    712806        int someValue;
    713807};
    714 \end{cfacode} & == & \begin{cfacode}[tabsize=3]
     808\end{cfa} & == & \begin{cfa}[tabsize=3]
    715809struct MyCoroutine {
    716810        int someValue;
     
    726820
    727821void main(struct MyCoroutine* this);
    728 \end{cfacode}
     822\end{cfa}
    729823\end{tabular}
    730824\end{center}
     
    736830Both user and kernel threads are supported, where user threads are the concurrency mechanism and kernel threads are the parallel mechanism.
    737831User threads offer a flexible and lightweight interface.
    738 A thread can be declared using a struct declaration \code{thread} as follows:
    739 
    740 \begin{cfacode}
     832A thread can be declared using a struct declaration @thread@ as follows:
     833
     834\begin{cfa}
    741835thread foo {};
    742 \end{cfacode}
     836\end{cfa}
    743837
    744838As for coroutines, the keyword is a thin wrapper around a \CFA trait:
    745839
    746 \begin{cfacode}
     840\begin{cfa}
    747841trait is_thread(dtype T) {
    748842      void ^?{}(T & mutex this);
     
    750844      thread_desc* get_thread(T & this);
    751845};
    752 \end{cfacode}
     846\end{cfa}
    753847
    754848Obviously, for this thread implementation to be useful it must run some user code.
    755849Several other threading interfaces use a function-pointer representation as the interface of threads (for example \Csharp~\cite{Csharp} and Scala~\cite{Scala}).
    756 However, this proposal considers that statically tying a \code{main} routine to a thread supersedes this approach.
    757 Since the \code{main} routine is already a special routine in \CFA (where the program begins), it is a natural extension of the semantics to use overloading to declare mains for different threads (the normal main being the main of the initial thread).
    758 As such the \code{main} routine of a thread can be defined as
    759 \begin{cfacode}
     850However, this proposal considers that statically tying a @main@ routine to a thread supersedes this approach.
     851Since the @main@ routine is already a special routine in \CFA (where the program begins), it is a natural extension of the semantics to use overloading to declare mains for different threads (the normal main being the main of the initial thread).
     852As such the @main@ routine of a thread can be defined as
     853\begin{cfa}
    760854thread foo {};
    761855
     
    763857        sout | "Hello World!" | endl;
    764858}
    765 \end{cfacode}
    766 
    767 In this example, threads of type \code{foo} start execution in the \code{void main(foo &)} routine, which prints \code{"Hello World!".} While this paper encourages this approach to enforce strongly typed programming, users may prefer to use the routine-based thread semantics for the sake of simplicity.
     859\end{cfa}
     860
     861In this example, threads of type @foo@ start execution in the @void main(foo &)@ routine, which prints @"Hello World!".@ While this paper encourages this approach to enforce strongly typed programming, users may prefer to use the routine-based thread semantics for the sake of simplicity.
    768862With the static semantics it is trivial to write a thread type that takes a function pointer as a parameter and executes it on its stack asynchronously.
    769 \begin{cfacode}
     863\begin{cfa}
    770864typedef void (*voidFunc)(int);
    771865
     
    781875
    782876void main(FuncRunner & this) {
    783         //thread starts here and runs the function
     877        // thread starts here and runs the function
    784878        this.func( this.arg );
    785879}
     
    793887        return 0?
    794888}
    795 \end{cfacode}
     889\end{cfa}
    796890
    797891A consequence of the strongly typed approach to main is that memory layout of parameters and return values to/from a thread are now explicitly specified in the \textbf{api}.
    798892
    799893Of course, for threads to be useful, it must be possible to start and stop threads and wait for them to complete execution.
    800 While using an \textbf{api} such as \code{fork} and \code{join} is relatively common in the literature, such an interface is unnecessary.
    801 Indeed, the simplest approach is to use \textbf{raii} principles and have threads \code{fork} after the constructor has completed and \code{join} before the destructor runs.
    802 \begin{cfacode}
     894While using an \textbf{api} such as @fork@ and @join@ is relatively common in the literature, such an interface is unnecessary.
     895Indeed, the simplest approach is to use \textbf{raii} principles and have threads @fork@ after the constructor has completed and @join@ before the destructor runs.
     896\begin{cfa}
    803897thread World;
    804898
     
    809903void main() {
    810904        World w;
    811         //Thread forks here
    812 
    813         //Printing "Hello " and "World!" are run concurrently
     905        // Thread forks here
     906
     907        // Printing "Hello " and "World!" are run concurrently
    814908        sout | "Hello " | endl;
    815909
    816         //Implicit join at end of scope
    817 }
    818 \end{cfacode}
     910        // Implicit join at end of scope
     911}
     912\end{cfa}
    819913
    820914This semantic has several advantages over explicit semantics: a thread is always started and stopped exactly once, users cannot make any programming errors, and it naturally scales to multiple threads meaning basic synchronization is very simple.
    821915
    822 \begin{cfacode}
     916\begin{cfa}
    823917thread MyThread {
    824918        //...
    825919};
    826920
    827 //main
     921// main
    828922void main(MyThread& this) {
    829923        //...
     
    832926void foo() {
    833927        MyThread thrds[10];
    834         //Start 10 threads at the beginning of the scope
     928        // Start 10 threads at the beginning of the scope
    835929
    836930        DoStuff();
    837931
    838         //Wait for the 10 threads to finish
    839 }
    840 \end{cfacode}
     932        // Wait for the 10 threads to finish
     933}
     934\end{cfa}
    841935
    842936However, one of the drawbacks of this approach is that threads always form a tree where nodes must always outlive their children, i.e., they are always destroyed in the opposite order of construction because of C scoping rules.
    843937This restriction is relaxed by using dynamic allocation, so threads can outlive the scope in which they are created, much like dynamically allocating memory lets objects outlive the scope in which they are created.
    844938
    845 \begin{cfacode}
     939\begin{cfa}
    846940thread MyThread {
    847941        //...
     
    855949        MyThread* long_lived;
    856950        {
    857                 //Start a thread at the beginning of the scope
     951                // Start a thread at the beginning of the scope
    858952                MyThread short_lived;
    859953
    860                 //create another thread that will outlive the thread in this scope
     954                // create another thread that will outlive the thread in this scope
    861955                long_lived = new MyThread;
    862956
    863957                DoStuff();
    864958
    865                 //Wait for the thread short_lived to finish
     959                // Wait for the thread short_lived to finish
    866960        }
    867961        DoMoreStuff();
    868962
    869         //Now wait for the long_lived to finish
     963        // Now wait for the long_lived to finish
    870964        delete long_lived;
    871965}
    872 \end{cfacode}
     966\end{cfa}
    873967
    874968
     
    888982At the lowest level, concurrent paradigms are implemented as atomic operations and locks.
    889983Many such mechanisms have been proposed, including semaphores~\cite{Dijkstra68b} and path expressions~\cite{Campbell74}.
    890 However, for productivity reasons it is desirable to have a higher-level construct be the core concurrency paradigm~\cite{HPP:Study}.
     984However, for productivity reasons it is desirable to have a higher-level construct be the core concurrency paradigm~\cite{Hochstein05}.
    891985
    892986An approach that is worth mentioning because it is gaining in popularity is transactional memory~\cite{Herlihy93}.
     
    9091003Methods range from low-level locks, which are fast and flexible but require significant attention to be correct, to  higher-level concurrency techniques, which sacrifice some performance in order to improve ease of use.
    9101004Ease of use comes 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.
    911 For example, the \CC \code{std::atomic<T>} offers an easy way to express mutual-exclusion on a restricted set of operations (e.g., reading/writing large types atomically).
     1005For example, the \CC @std::atomic<T>@ offers an easy way to express mutual-exclusion on a restricted set of operations (e.g., reading/writing large types atomically).
    9121006Another challenge with low-level locks is composability.
    9131007Locks have restricted composability because it takes careful organizing for multiple locks to be used while preventing deadlocks.
     
    9381032This concept is generally associated with object-oriented languages like Java~\cite{Java} or \uC~\cite{uC++book} but does not strictly require OO semantics.
    9391033The only requirement is the ability to declare a handle to a shared object and a set of routines that act on it:
    940 \begin{cfacode}
     1034\begin{cfa}
    9411035typedef /*some monitor type*/ monitor;
    9421036int f(monitor & m);
    9431037
    9441038int main() {
    945         monitor m;  //Handle m
    946         f(m);       //Routine using handle
    947 }
    948 \end{cfacode}
     1039        monitor m;  // Handle m
     1040        f(m);       // Routine using handle
     1041}
     1042\end{cfa}
    9491043
    9501044% ======================================================================
     
    9561050First, it is necessary to use pass-by-reference over pass-by-value for monitor routines.
    9571051This semantics is important, because at their core, monitors are implicit mutual-exclusion objects (locks), and these objects cannot be copied.
    958 Therefore, monitors are non-copy-able objects (\code{dtype}).
     1052Therefore, monitors are non-copy-able objects (@dtype@).
    9591053
    9601054Another aspect to consider is when a monitor acquires its mutual exclusion.
    9611055For example, a monitor may need to be passed through multiple helper routines that do not acquire the monitor mutual-exclusion on entry.
    962 Passthrough can occur for generic helper routines (\code{swap}, \code{sort}, etc.) or specific helper routines like the following to implement an atomic counter:
    963 
    964 \begin{cfacode}
     1056Passthrough can occur for generic helper routines (@swap@, @sort@, etc.) or specific helper routines like the following to implement an atomic counter:
     1057
     1058\begin{cfa}
    9651059monitor counter_t { /*...see section $\ref{data}$...*/ };
    9661060
    967 void ?{}(counter_t & nomutex this); //constructor
    968 size_t ++?(counter_t & mutex this); //increment
    969 
    970 //need for mutex is platform dependent
    971 void ?{}(size_t * this, counter_t & mutex cnt); //conversion
    972 \end{cfacode}
     1061void ?{}(counter_t & nomutex this); // constructor
     1062size_t ++?(counter_t & mutex this); // increment
     1063
     1064// need for mutex is platform dependent
     1065void ?{}(size_t * this, counter_t & mutex cnt); // conversion
     1066\end{cfa}
    9731067This counter is used as follows:
    9741068\begin{center}
    9751069\begin{tabular}{c @{\hskip 0.35in} c @{\hskip 0.35in} c}
    976 \begin{cfacode}
    977 //shared counter
     1070\begin{cfa}
     1071// shared counter
    9781072counter_t cnt1, cnt2;
    9791073
    980 //multiple threads access counter
     1074// multiple threads access counter
    9811075thread 1 : cnt1++; cnt2++;
    9821076thread 2 : cnt1++; cnt2++;
     
    9841078        ...
    9851079thread N : cnt1++; cnt2++;
    986 \end{cfacode}
     1080\end{cfa}
    9871081\end{tabular}
    9881082\end{center}
    989 Notice how the counter is used without any explicit synchronization and yet supports thread-safe semantics for both reading and writing, which is similar in usage to the \CC template \code{std::atomic}.
    990 
    991 Here, the constructor (\code{?\{\}}) uses the \code{nomutex} keyword to signify that it does not acquire the monitor mutual-exclusion when constructing.
    992 This semantics is because an object not yet con\-structed should never be shared and therefore does not require mutual exclusion.
     1083Notice how the counter is used without any explicit synchronization and yet supports thread-safe semantics for both reading and writing, which is similar in usage to the \CC template @std::atomic@.
     1084
     1085Here, the constructor (@?{}@) uses the @nomutex@ keyword to signify that it does not acquire the monitor mutual-exclusion when constructing.
     1086This semantics is because an object not yet constructed should never be shared and therefore does not require mutual exclusion.
    9931087Furthermore, it allows the implementation greater freedom when it initializes the monitor locking.
    994 The prefix increment operator uses \code{mutex} to protect the incrementing process from race conditions.
    995 Finally, there is a conversion operator from \code{counter_t} to \code{size_t}.
    996 This conversion may or may not require the \code{mutex} keyword depending on whether or not reading a \code{size_t} is an atomic operation.
     1088The prefix increment operator uses @mutex@ to protect the incrementing process from race conditions.
     1089Finally, there is a conversion operator from @counter_t@ to @size_t@.
     1090This conversion may or may not require the @mutex@ keyword depending on whether or not reading a @size_t@ is an atomic operation.
    9971091
    9981092For maximum usability, monitors use \textbf{multi-acq} semantics, which means a single thread can acquire the same monitor multiple times without deadlock.
    9991093For example, listing \ref{fig:search} uses recursion and \textbf{multi-acq} to print values inside a binary tree.
    10001094\begin{figure}
    1001 \begin{cfacode}[caption={Recursive printing algorithm using \textbf{multi-acq}.},label={fig:search}]
     1095\begin{cfa}[caption={Recursive printing algorithm using \textbf{multi-acq}.},label={fig:search}]
    10021096monitor printer { ... };
    10031097struct tree {
     
    10121106        print(p, t->right);
    10131107}
    1014 \end{cfacode}
     1108\end{cfa}
    10151109\end{figure}
    10161110
    1017 Having both \code{mutex} and \code{nomutex} keywords can be redundant, depending on the meaning of a routine having neither of these keywords.
    1018 For example, it is reasonable that it should default to the safest option (\code{mutex}) when given a routine without qualifiers \code{void foo(counter_t & this)}, whereas assuming \code{nomutex} is unsafe and may cause subtle errors.
    1019 On the other hand, \code{nomutex} is the ``normal'' parameter behaviour, it effectively states explicitly that ``this routine is not special''.
     1111Having both @mutex@ and @nomutex@ keywords can be redundant, depending on the meaning of a routine having neither of these keywords.
     1112For example, it is reasonable that it should default to the safest option (@mutex@) when given a routine without qualifiers @void foo(counter_t & this)@, whereas assuming @nomutex@ is unsafe and may cause subtle errors.
     1113On the other hand, @nomutex@ is the ``normal'' parameter behaviour, it effectively states explicitly that ``this routine is not special''.
    10201114Another alternative is making exactly one of these keywords mandatory, which provides the same semantics but without the ambiguity of supporting routines with neither keyword.
    10211115Mandatory keywords would also have the added benefit of being self-documented but at the cost of extra typing.
     
    10231117Mandatory keywords in \CFA would imply that the compiler must know without doubt whether or not a parameter is a monitor or not.
    10241118Since \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.
    1025 For this reason, \CFA only has the \code{mutex} keyword and uses no keyword to mean \code{nomutex}.
    1026 
    1027 The next semantic decision is to establish when \code{mutex} may be used as a type qualifier.
     1119For this reason, \CFA only has the @mutex@ keyword and uses no keyword to mean @nomutex@.
     1120
     1121The next semantic decision is to establish when @mutex@ may be used as a type qualifier.
    10281122Consider the following declarations:
    1029 \begin{cfacode}
     1123\begin{cfa}
    10301124int f1(monitor & mutex m);
    10311125int f2(const monitor & mutex m);
     
    10331127int f4(monitor * mutex m []);
    10341128int f5(graph(monitor *) & mutex m);
    1035 \end{cfacode}
     1129\end{cfa}
    10361130The problem is to identify which object(s) should be acquired.
    10371131Furthermore, each object needs to be acquired only once.
    1038 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.
    1039 Adding indirections (\code{f3}) still allows the compiler and programmer to identify which object is acquired.
    1040 However, adding in arrays (\code{f4}) makes it much harder.
     1132In the case of simple routines like @f1@ and @f2@ it is easy to identify an exhaustive list of objects to acquire on entry.
     1133Adding indirections (@f3@) still allows the compiler and programmer to identify which object is acquired.
     1134However, adding in arrays (@f4@) makes it much harder.
    10411135Array lengths are not necessarily known in C, and even then, making sure objects are only acquired once becomes none-trivial.
    1042 This problem can be extended to absurd limits like \code{f5}, which uses a graph of monitors.
     1136This problem can be extended to absurd limits like @f5@, which uses a graph of monitors.
    10431137To make the issue tractable, this project imposes the requirement that a routine may only acquire one monitor per parameter and it must be the type of the parameter with at most one level of indirection (ignoring potential qualifiers).
    1044 Also note that while routine \code{f3} can be supported, meaning that monitor \code{**m} is acquired, passing an array to this routine would be type-safe and yet result in undefined behaviour because only the first element of the array is acquired.
     1138Also note that while routine @f3@ can be supported, meaning that monitor @**m@ is acquired, passing an array to this routine would be type-safe and yet result in undefined behaviour because only the first element of the array is acquired.
    10451139However, this ambiguity is part of the C type-system with respects to arrays.
    1046 For this reason, \code{mutex} is disallowed in the context where arrays may be passed:
    1047 \begin{cfacode}
    1048 int f1(monitor & mutex m);    //Okay : recommended case
    1049 int f2(monitor * mutex m);    //Not Okay : Could be an array
    1050 int f3(monitor mutex m []);  //Not Okay : Array of unknown length
    1051 int f4(monitor ** mutex m);   //Not Okay : Could be an array
    1052 int f5(monitor * mutex m []); //Not Okay : Array of unknown length
    1053 \end{cfacode}
     1140For this reason, @mutex@ is disallowed in the context where arrays may be passed:
     1141\begin{cfa}
     1142int f1(monitor & mutex m);    // Okay : recommended case
     1143int f2(monitor * mutex m);    // Not Okay : Could be an array
     1144int f3(monitor mutex m []);  // Not Okay : Array of unknown length
     1145int f4(monitor ** mutex m);   // Not Okay : Could be an array
     1146int f5(monitor * mutex m []); // Not Okay : Array of unknown length
     1147\end{cfa}
    10541148Note that not all array functions are actually distinct in the type system.
    10551149However, even if the code generation could tell the difference, the extra information is still not sufficient to extend meaningfully the monitor call semantic.
     
    10571151Unlike object-oriented monitors, where calling a mutex member \emph{implicitly} acquires mutual-exclusion of the receiver object, \CFA uses an explicit mechanism to specify the object that acquires mutual-exclusion.
    10581152A consequence of this approach is that it extends naturally to multi-monitor calls.
    1059 \begin{cfacode}
     1153\begin{cfa}
    10601154int f(MonitorA & mutex a, MonitorB & mutex b);
    10611155
     
    10631157MonitorB b;
    10641158f(a,b);
    1065 \end{cfacode}
     1159\end{cfa}
    10661160While OO monitors could be extended with a mutex qualifier for multiple-monitor calls, no example of this feature could be found.
    10671161The capability to acquire multiple locks before entering a critical section is called \emph{\textbf{bulk-acq}}.
     
    10711165This consistent ordering means acquiring multiple monitors is safe from deadlock when using \textbf{bulk-acq}.
    10721166However, users can still force the acquiring order.
    1073 For example, notice which routines use \code{mutex}/\code{nomutex} and how this affects acquiring order:
    1074 \begin{cfacode}
    1075 void foo(A& mutex a, B& mutex b) { //acquire a & b
     1167For example, notice which routines use @mutex@/@nomutex@ and how this affects acquiring order:
     1168\begin{cfa}
     1169void foo(A& mutex a, B& mutex b) { // acquire a & b
    10761170        ...
    10771171}
    10781172
    1079 void bar(A& mutex a, B& /*nomutex*/ b) { //acquire a
    1080         ... foo(a, b); ... //acquire b
    1081 }
    1082 
    1083 void baz(A& /*nomutex*/ a, B& mutex b) { //acquire b
    1084         ... foo(a, b); ... //acquire a
    1085 }
    1086 \end{cfacode}
    1087 The \textbf{multi-acq} monitor lock allows a monitor lock to be acquired by both \code{bar} or \code{baz} and acquired again in \code{foo}.
    1088 In the calls to \code{bar} and \code{baz} the monitors are acquired in opposite order.
     1173void bar(A& mutex a, B& /*nomutex*/ b) { // acquire a
     1174        ... foo(a, b); ... // acquire b
     1175}
     1176
     1177void baz(A& /*nomutex*/ a, B& mutex b) { // acquire b
     1178        ... foo(a, b); ... // acquire a
     1179}
     1180\end{cfa}
     1181The \textbf{multi-acq} monitor lock allows a monitor lock to be acquired by both @bar@ or @baz@ and acquired again in @foo@.
     1182In the calls to @bar@ and @baz@ the monitors are acquired in opposite order.
    10891183
    10901184However, such use leads to lock acquiring order problems.
    1091 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}.
     1185In the example above, the user uses implicit ordering in the case of function @foo@ but explicit ordering in the case of @bar@ and @baz@.
    10921186This subtle difference means that calling these routines concurrently may lead to deadlock and is therefore undefined behaviour.
    10931187As shown~\cite{Lister77}, solving this problem requires:
     
    11011195
    11021196For example, \textbf{multi-acq} and \textbf{bulk-acq} can be used together in interesting ways:
    1103 \begin{cfacode}
     1197\begin{cfa}
    11041198monitor bank { ... };
    11051199
     
    11101204        deposit( yourbank, me2you );
    11111205}
    1112 \end{cfacode}
     1206\end{cfa}
    11131207This example shows a trivial solution to the bank-account transfer problem~\cite{BankTransfer}.
    11141208Without \textbf{multi-acq} and \textbf{bulk-acq}, the solution to this problem is much more involved and requires careful engineering.
    11151209
    1116 \subsection{\code{mutex} statement} \label{mutex-stmt}
    1117 
    1118 The call semantics discussed above have one software engineering issue: only a routine can acquire the mutual-exclusion of a set of monitor. \CFA offers the \code{mutex} statement to work around the need for unnecessary names, avoiding a major software engineering problem~\cite{2FTwoHardThings}.
    1119 Table \ref{lst:mutex-stmt} shows an example of the \code{mutex} statement, which introduces a new scope in which the mutual-exclusion of a set of monitor is acquired.
    1120 Beyond naming, the \code{mutex} statement has no semantic difference from a routine call with \code{mutex} parameters.
     1210
     1211\subsection{\protect\lstinline|mutex| statement} \label{mutex-stmt}
     1212
     1213The call semantics discussed above have one software engineering issue: only a routine can acquire the mutual-exclusion of a set of monitor. \CFA offers the @mutex@ statement to work around the need for unnecessary names, avoiding a major software engineering problem~\cite{2FTwoHardThings}.
     1214Table \ref{lst:mutex-stmt} shows an example of the @mutex@ statement, which introduces a new scope in which the mutual-exclusion of a set of monitor is acquired.
     1215Beyond naming, the @mutex@ statement has no semantic difference from a routine call with @mutex@ parameters.
    11211216
    11221217\begin{table}
    11231218\begin{center}
    11241219\begin{tabular}{|c|c|}
    1125 function call & \code{mutex} statement \\
     1220function call & @mutex@ statement \\
    11261221\hline
    1127 \begin{cfacode}[tabsize=3]
     1222\begin{cfa}[tabsize=3]
    11281223monitor M {};
    11291224void foo( M & mutex m1, M & mutex m2 ) {
    1130         //critical section
     1225        // critical section
    11311226}
    11321227
     
    11341229        foo( m1, m2 );
    11351230}
    1136 \end{cfacode}&\begin{cfacode}[tabsize=3]
     1231\end{cfa}&\begin{cfa}[tabsize=3]
    11371232monitor M {};
    11381233void bar( M & m1, M & m2 ) {
    11391234        mutex(m1, m2) {
    1140                 //critical section
    1141         }
    1142 }
    1143 
    1144 
    1145 \end{cfacode}
     1235                // critical section
     1236        }
     1237}
     1238
     1239
     1240\end{cfa}
    11461241\end{tabular}
    11471242\end{center}
    1148 \caption{Regular call semantics vs. \code{mutex} statement}
     1243\caption{Regular call semantics vs. \protect\lstinline|mutex| statement}
    11491244\label{lst:mutex-stmt}
    11501245\end{table}
     
    11591254This data should be intrinsic to the monitor declaration to prevent any accidental use of data without its appropriate protection.
    11601255For example, here is a complete version of the counter shown in section \ref{call}:
    1161 \begin{cfacode}
     1256\begin{cfa}
    11621257monitor counter_t {
    11631258        int value;
     
    11721267}
    11731268
    1174 //need for mutex is platform dependent here
     1269// need for mutex is platform dependent here
    11751270void ?{}(int * this, counter_t & mutex cnt) {
    11761271        *this = (int)cnt;
    11771272}
    1178 \end{cfacode}
    1179 
    1180 Like threads and coroutines, monitors are defined in terms of traits with some additional language support in the form of the \code{monitor} keyword.
     1273\end{cfa}
     1274
     1275Like threads and coroutines, monitors are defined in terms of traits with some additional language support in the form of the @monitor@ keyword.
    11811276The monitor trait is:
    1182 \begin{cfacode}
     1277\begin{cfa}
    11831278trait is_monitor(dtype T) {
    11841279        monitor_desc * get_monitor( T & );
    11851280        void ^?{}( T & mutex );
    11861281};
    1187 \end{cfacode}
    1188 Note that the destructor of a monitor must be a \code{mutex} routine to prevent deallocation while a thread is accessing the monitor.
    1189 As with any object, calls to a monitor, using \code{mutex} or otherwise, is undefined behaviour after the destructor has run.
     1282\end{cfa}
     1283Note that the destructor of a monitor must be a @mutex@ routine to prevent deallocation while a thread is accessing the monitor.
     1284As with any object, calls to a monitor, using @mutex@ or otherwise, is undefined behaviour after the destructor has run.
    11901285
    11911286% ======================================================================
     
    12021297First, here is a simple example of internal scheduling:
    12031298
    1204 \begin{cfacode}
     1299\begin{cfa}
    12051300monitor A {
    12061301        condition e;
     
    12091304void foo(A& mutex a1, A& mutex a2) {
    12101305        ...
    1211         //Wait for cooperation from bar()
     1306        // Wait for cooperation from bar()
    12121307        wait(a1.e);
    12131308        ...
     
    12151310
    12161311void bar(A& mutex a1, A& mutex a2) {
    1217         //Provide cooperation for foo()
     1312        // Provide cooperation for foo()
    12181313        ...
    1219         //Unblock foo
     1314        // Unblock foo
    12201315        signal(a1.e);
    12211316}
    1222 \end{cfacode}
     1317\end{cfa}
    12231318There are two details to note here.
    1224 First, \code{signal} is a delayed operation; it only unblocks the waiting thread when it reaches the end of the critical section.
     1319First, @signal@ is a delayed operation; it only unblocks the waiting thread when it reaches the end of the critical section.
    12251320This semantics is needed to respect mutual-exclusion, i.e., the signaller and signalled thread cannot be in the monitor simultaneously.
    1226 The alternative is to return immediately after the call to \code{signal}, which is significantly more restrictive.
    1227 Second, in \CFA, while it is common to store a \code{condition} as a field of the monitor, a \code{condition} variable can be stored/created independently of a monitor.
    1228 Here routine \code{foo} waits for the \code{signal} from \code{bar} before making further progress, ensuring a basic ordering.
    1229 
    1230 An important aspect of the implementation is that \CFA does not allow barging, which means that once function \code{bar} releases the monitor, \code{foo} is guaranteed to be the next thread to acquire the monitor (unless some other thread waited on the same condition).
     1321The alternative is to return immediately after the call to @signal@, which is significantly more restrictive.
     1322Second, in \CFA, while it is common to store a @condition@ as a field of the monitor, a @condition@ variable can be stored/created independently of a monitor.
     1323Here routine @foo@ waits for the @signal@ from @bar@ before making further progress, ensuring a basic ordering.
     1324
     1325An important aspect of the implementation is that \CFA does not allow barging, which means that once function @bar@ releases the monitor, @foo@ is guaranteed to be the next thread to acquire the monitor (unless some other thread waited on the same condition).
    12311326This guarantee offers the benefit of not having to loop around waits to recheck that a condition is met.
    12321327The 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.
     
    12401335It is easy to understand the problem of multi-monitor scheduling using a series of pseudo-code examples.
    12411336Note 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.
    1242 Indeed, \code{wait} statements always use the implicit condition variable as parameters and explicitly name the monitors (A and B) associated with the condition.
     1337Indeed, @wait@ statements always use the implicit condition variable as parameters and explicitly name the monitors (A and B) associated with the condition.
    12431338Note that in \CFA, condition variables are tied to a \emph{group} of monitors on first use (called branding), which means that using internal scheduling with distinct sets of monitors requires one condition variable per set of monitors.
    12441339The example below shows the simple case of having two threads (one for each column) and a single monitor A.
     
    12461341\begin{multicols}{2}
    12471342thread 1
    1248 \begin{pseudo}
     1343\begin{cfa}
    12491344acquire A
    12501345        wait A
    12511346release A
    1252 \end{pseudo}
     1347\end{cfa}
    12531348
    12541349\columnbreak
    12551350
    12561351thread 2
    1257 \begin{pseudo}
     1352\begin{cfa}
    12581353acquire A
    12591354        signal A
    12601355release A
    1261 \end{pseudo}
     1356\end{cfa}
    12621357\end{multicols}
    12631358One thread acquires before waiting (atomically blocking and releasing A) and the other acquires before signalling.
    1264 It is important to note here that both \code{wait} and \code{signal} must be called with the proper monitor(s) already acquired.
     1359It is important to note here that both @wait@ and @signal@ must be called with the proper monitor(s) already acquired.
    12651360This semantic is a logical requirement for barging prevention.
    12661361
    12671362A direct extension of the previous example is a \textbf{bulk-acq} version:
    12681363\begin{multicols}{2}
    1269 \begin{pseudo}
     1364\begin{cfa}
    12701365acquire A & B
    12711366        wait A & B
    12721367release A & B
    1273 \end{pseudo}
     1368\end{cfa}
    12741369\columnbreak
    1275 \begin{pseudo}
     1370\begin{cfa}
    12761371acquire A & B
    12771372        signal A & B
    12781373release A & B
    1279 \end{pseudo}
     1374\end{cfa}
    12801375\end{multicols}
    12811376\noindent This version uses \textbf{bulk-acq} (denoted using the {\sf\&} symbol), but the presence of multiple monitors does not add a particularly new meaning.
     
    12851380
    12861381While 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.
    1287 For monitors, a well-known deadlock problem is the Nested Monitor Problem~\cite{Lister77}, which occurs when a \code{wait} is made by a thread that holds more than one monitor.
    1288 For example, the following pseudo-code runs into the nested-monitor problem:
     1382For monitors, a well-known deadlock problem is the Nested Monitor Problem~\cite{Lister77}, which occurs when a @wait@ is made by a thread that holds more than one monitor.
     1383For example, the following cfa-code runs into the nested-monitor problem:
    12891384\begin{multicols}{2}
    1290 \begin{pseudo}
     1385\begin{cfa}
    12911386acquire A
    12921387        acquire B
     
    12941389        release B
    12951390release A
    1296 \end{pseudo}
     1391\end{cfa}
    12971392
    12981393\columnbreak
    12991394
    1300 \begin{pseudo}
     1395\begin{cfa}
    13011396acquire A
    13021397        acquire B
     
    13041399        release B
    13051400release A
    1306 \end{pseudo}
     1401\end{cfa}
    13071402\end{multicols}
    1308 \noindent The \code{wait} only releases monitor \code{B} so the signalling thread cannot acquire monitor \code{A} to get to the \code{signal}.
    1309 Attempting release of all acquired monitors at the \code{wait} introduces a different set of problems, such as releasing monitor \code{C}, which has nothing to do with the \code{signal}.
     1403\noindent The @wait@ only releases monitor @B@ so the signalling thread cannot acquire monitor @A@ to get to the @signal@.
     1404Attempting release of all acquired monitors at the @wait@ introduces a different set of problems, such as releasing monitor @C@, which has nothing to do with the @signal@.
    13101405
    13111406However, for monitors as for locks, it is possible to write a program using nesting without encountering any problems if nesting is done correctly.
    1312 For example, the next pseudo-code snippet acquires monitors {\sf A} then {\sf B} before waiting, while only acquiring {\sf B} when signalling, effectively avoiding the Nested Monitor Problem~\cite{Lister77}.
     1407For example, the next cfa-code snippet acquires monitors {\sf A} then {\sf B} before waiting, while only acquiring {\sf B} when signalling, effectively avoiding the Nested Monitor Problem~\cite{Lister77}.
    13131408
    13141409\begin{multicols}{2}
    1315 \begin{pseudo}
     1410\begin{cfa}
    13161411acquire A
    13171412        acquire B
     
    13191414        release B
    13201415release A
    1321 \end{pseudo}
     1416\end{cfa}
    13221417
    13231418\columnbreak
    13241419
    1325 \begin{pseudo}
     1420\begin{cfa}
    13261421
    13271422acquire B
     
    13291424release B
    13301425
    1331 \end{pseudo}
     1426\end{cfa}
    13321427\end{multicols}
    13331428
     
    13411436
    13421437A larger example is presented to show complex issues for \textbf{bulk-acq} and its implementation options are analyzed.
    1343 Listing \ref{lst:int-bulk-pseudo} shows an example where \textbf{bulk-acq} adds a significant layer of complexity to the internal signalling semantics, and listing \ref{lst:int-bulk-cfa} shows the corresponding \CFA code to implement the pseudo-code in listing \ref{lst:int-bulk-pseudo}.
    1344 For the purpose of translating the given pseudo-code into \CFA-code, any method of introducing a monitor is acceptable, e.g., \code{mutex} parameters, global variables, pointer parameters, or using locals with the \code{mutex} statement.
     1438Listing \ref{lst:int-bulk-cfa} shows an example where \textbf{bulk-acq} adds a significant layer of complexity to the internal signalling semantics, and listing \ref{lst:int-bulk-cfa} shows the corresponding \CFA code to implement the cfa-code in listing \ref{lst:int-bulk-cfa}.
     1439For the purpose of translating the given cfa-code into \CFA-code, any method of introducing a monitor is acceptable, e.g., @mutex@ parameters, global variables, pointer parameters, or using locals with the @mutex@ statement.
    13451440
    13461441\begin{figure}[!t]
    13471442\begin{multicols}{2}
    13481443Waiting thread
    1349 \begin{pseudo}[numbers=left]
     1444\begin{cfa}[numbers=left]
    13501445acquire A
    1351         //Code Section 1
     1446        // Code Section 1
    13521447        acquire A & B
    1353                 //Code Section 2
     1448                // Code Section 2
    13541449                wait A & B
    1355                 //Code Section 3
     1450                // Code Section 3
    13561451        release A & B
    1357         //Code Section 4
     1452        // Code Section 4
    13581453release A
    1359 \end{pseudo}
     1454\end{cfa}
    13601455\columnbreak
    13611456Signalling thread
    1362 \begin{pseudo}[numbers=left, firstnumber=10,escapechar=|]
     1457\begin{cfa}[numbers=left, firstnumber=10,escapechar=|]
    13631458acquire A
    1364         //Code Section 5
     1459        // Code Section 5
    13651460        acquire A & B
    1366                 //Code Section 6
     1461                // Code Section 6
    13671462                |\label{line:signal1}|signal A & B
    1368                 //Code Section 7
     1463                // Code Section 7
    13691464        |\label{line:releaseFirst}|release A & B
    1370         //Code Section 8
     1465        // Code Section 8
    13711466|\label{line:lastRelease}|release A
    1372 \end{pseudo}
     1467\end{cfa}
    13731468\end{multicols}
    1374 \begin{cfacode}[caption={Internal scheduling with \textbf{bulk-acq}},label={lst:int-bulk-pseudo}]
    1375 \end{cfacode}
     1469\begin{cfa}[caption={Internal scheduling with \textbf{bulk-acq}},label={lst:int-bulk-cfa}]
     1470\end{cfa}
    13761471\begin{center}
    1377 \begin{cfacode}[xleftmargin=.4\textwidth]
     1472\begin{cfa}[xleftmargin=.4\textwidth]
    13781473monitor A a;
    13791474monitor B b;
    13801475condition c;
    1381 \end{cfacode}
     1476\end{cfa}
    13821477\end{center}
    13831478\begin{multicols}{2}
    13841479Waiting thread
    1385 \begin{cfacode}
     1480\begin{cfa}
    13861481mutex(a) {
    1387         //Code Section 1
     1482        // Code Section 1
    13881483        mutex(a, b) {
    1389                 //Code Section 2
     1484                // Code Section 2
    13901485                wait(c);
    1391                 //Code Section 3
    1392         }
    1393         //Code Section 4
    1394 }
    1395 \end{cfacode}
     1486                // Code Section 3
     1487        }
     1488        // Code Section 4
     1489}
     1490\end{cfa}
    13961491\columnbreak
    13971492Signalling thread
    1398 \begin{cfacode}
     1493\begin{cfa}
    13991494mutex(a) {
    1400         //Code Section 5
     1495        // Code Section 5
    14011496        mutex(a, b) {
    1402                 //Code Section 6
     1497                // Code Section 6
    14031498                signal(c);
    1404                 //Code Section 7
    1405         }
    1406         //Code Section 8
    1407 }
    1408 \end{cfacode}
     1499                // Code Section 7
     1500        }
     1501        // Code Section 8
     1502}
     1503\end{cfa}
    14091504\end{multicols}
    1410 \begin{cfacode}[caption={Equivalent \CFA code for listing \ref{lst:int-bulk-pseudo}},label={lst:int-bulk-cfa}]
    1411 \end{cfacode}
     1505\begin{cfa}[caption={Equivalent \CFA code for listing \ref{lst:int-bulk-cfa}},label={lst:int-bulk-cfa}]
     1506\end{cfa}
    14121507\begin{multicols}{2}
    14131508Waiter
    1414 \begin{pseudo}[numbers=left]
     1509\begin{cfa}[numbers=left]
    14151510acquire A
    14161511        acquire A & B
     
    14181513        release A & B
    14191514release A
    1420 \end{pseudo}
     1515\end{cfa}
    14211516
    14221517\columnbreak
    14231518
    14241519Signaller
    1425 \begin{pseudo}[numbers=left, firstnumber=6,escapechar=|]
     1520\begin{cfa}[numbers=left, firstnumber=6,escapechar=|]
    14261521acquire A
    14271522        acquire A & B
    14281523                signal A & B
    14291524        release A & B
    1430         |\label{line:secret}|//Secretly keep B here
     1525        |\label{line:secret}|// Secretly keep B here
    14311526release A
    1432 //Wakeup waiter and transfer A & B
    1433 \end{pseudo}
     1527// Wakeup waiter and transfer A & B
     1528\end{cfa}
    14341529\end{multicols}
    1435 \begin{cfacode}[caption={Listing \ref{lst:int-bulk-pseudo}, with delayed signalling comments},label={lst:int-secret}]
    1436 \end{cfacode}
     1530\begin{cfa}[caption={Listing \ref{lst:int-bulk-cfa}, with delayed signalling comments},label={lst:int-secret}]
     1531\end{cfa}
    14371532\end{figure}
    14381533
    1439 The complexity begins at code sections 4 and 8 in listing \ref{lst:int-bulk-pseudo}, which are where the existing semantics of internal scheduling needs to be extended for multiple monitors.
    1440 The root of the problem is that \textbf{bulk-acq} is used in a context where one of the monitors is already acquired, which is why it is important to define the behaviour of the previous pseudo-code.
    1441 When the signaller thread reaches the location where it should ``release \code{A & B}'' (listing \ref{lst:int-bulk-pseudo} line \ref{line:releaseFirst}), it must actually transfer ownership of monitor \code{B} to the waiting thread.
    1442 This ownership transfer is required in order to prevent barging into \code{B} by another thread, since both the signalling and signalled threads still need monitor \code{A}.
     1534The complexity begins at code sections 4 and 8 in listing \ref{lst:int-bulk-cfa}, which are where the existing semantics of internal scheduling needs to be extended for multiple monitors.
     1535The root of the problem is that \textbf{bulk-acq} is used in a context where one of the monitors is already acquired, which is why it is important to define the behaviour of the previous cfa-code.
     1536When the signaller thread reaches the location where it should ``release @A & B@'' (listing \ref{lst:int-bulk-cfa} line \ref{line:releaseFirst}), it must actually transfer ownership of monitor @B@ to the waiting thread.
     1537This ownership transfer is required in order to prevent barging into @B@ by another thread, since both the signalling and signalled threads still need monitor @A@.
    14431538There are three options:
    14441539
     
    14521547
    14531548However, listing \ref{lst:int-secret} shows this solution can become much more complicated depending on what is executed while secretly holding B at line \ref{line:secret}, while avoiding the need to transfer ownership of a subset of the condition monitors.
    1454 Listing \ref{lst:dependency} shows a slightly different example where a third thread is waiting on monitor \code{A}, using a different condition variable.
    1455 Because the third thread is signalled when secretly holding \code{B}, the goal  becomes unreachable.
     1549Listing \ref{lst:dependency} shows a slightly different example where a third thread is waiting on monitor @A@, using a different condition variable.
     1550Because the third thread is signalled when secretly holding @B@, the goal  becomes unreachable.
    14561551Depending on the order of signals (listing \ref{lst:dependency} line \ref{line:signal-ab} and \ref{line:signal-a}) two cases can happen:
    14571552
    1458 \paragraph{Case 1: thread $\alpha$ goes first.} In this case, the problem is that monitor \code{A} needs to be passed to thread $\beta$ when thread $\alpha$ is done with it.
    1459 \paragraph{Case 2: thread $\beta$ goes first.} In this case, the problem is that monitor \code{B} needs to be retained and passed to thread $\alpha$ along with monitor \code{A}, which can be done directly or possibly using thread $\beta$ as an intermediate.
     1553\paragraph{Case 1: thread $\alpha$ goes first.} In this case, the problem is that monitor @A@ needs to be passed to thread $\beta$ when thread $\alpha$ is done with it.
     1554\paragraph{Case 2: thread $\beta$ goes first.} In this case, the problem is that monitor @B@ needs to be retained and passed to thread $\alpha$ along with monitor @A@, which can be done directly or possibly using thread $\beta$ as an intermediate.
    14601555\\
    14611556
     
    14711566\begin{multicols}{3}
    14721567Thread $\alpha$
    1473 \begin{pseudo}[numbers=left, firstnumber=1]
     1568\begin{cfa}[numbers=left, firstnumber=1]
    14741569acquire A
    14751570        acquire A & B
     
    14771572        release A & B
    14781573release A
    1479 \end{pseudo}
     1574\end{cfa}
    14801575\columnbreak
    14811576Thread $\gamma$
    1482 \begin{pseudo}[numbers=left, firstnumber=6, escapechar=|]
     1577\begin{cfa}[numbers=left, firstnumber=6, escapechar=|]
    14831578acquire A
    14841579        acquire A & B
     
    14871582        |\label{line:signal-a}|signal A
    14881583|\label{line:release-a}|release A
    1489 \end{pseudo}
     1584\end{cfa}
    14901585\columnbreak
    14911586Thread $\beta$
    1492 \begin{pseudo}[numbers=left, firstnumber=12, escapechar=|]
     1587\begin{cfa}[numbers=left, firstnumber=12, escapechar=|]
    14931588acquire A
    14941589        wait A
    14951590|\label{line:release-aa}|release A
    1496 \end{pseudo}
     1591\end{cfa}
    14971592\end{multicols}
    1498 \begin{cfacode}[caption={Pseudo-code for the three thread example.},label={lst:dependency}]
    1499 \end{cfacode}
     1593\begin{cfa}[caption={Pseudo-code for the three thread example.},label={lst:dependency}]
     1594\end{cfa}
    15001595\begin{center}
    15011596\input{dependency}
     
    15051600\end{figure}
    15061601
    1507 In listing \ref{lst:int-bulk-pseudo}, there is a solution that satisfies both barging prevention and mutual exclusion.
    1508 If ownership of both monitors is transferred to the waiter when the signaller releases \code{A & B} and then the waiter transfers back ownership of \code{A} back to the signaller when it releases it, then the problem is solved (\code{B} is no longer in use at this point).
     1602In listing \ref{lst:int-bulk-cfa}, there is a solution that satisfies both barging prevention and mutual exclusion.
     1603If ownership of both monitors is transferred to the waiter when the signaller releases @A & B@ and then the waiter transfers back ownership of @A@ back to the signaller when it releases it, then the problem is solved (@B@ is no longer in use at this point).
    15091604Dynamically finding the correct order is therefore the second possible solution.
    15101605The problem is effectively resolving a dependency graph of ownership requirements.
     
    15141609\begin{figure}
    15151610\begin{multicols}{2}
    1516 \begin{pseudo}
     1611\begin{cfa}
    15171612acquire A
    15181613        acquire B
     
    15221617        release B
    15231618release A
    1524 \end{pseudo}
     1619\end{cfa}
    15251620
    15261621\columnbreak
    15271622
    1528 \begin{pseudo}
     1623\begin{cfa}
    15291624acquire A
    15301625        acquire B
     
    15341629        release B
    15351630release A
    1536 \end{pseudo}
     1631\end{cfa}
    15371632\end{multicols}
    1538 \begin{cfacode}[caption={Extension to three monitors of listing \ref{lst:int-bulk-pseudo}},label={lst:explosion}]
    1539 \end{cfacode}
     1633\begin{cfa}[caption={Extension to three monitors of listing \ref{lst:int-bulk-cfa}},label={lst:explosion}]
     1634\end{cfa}
    15401635\end{figure}
    15411636
     
    15461641\subsubsection{Partial Signalling} \label{partial-sig}
    15471642Finally, the solution that is chosen for \CFA is to use partial signalling.
    1548 Again using listing \ref{lst:int-bulk-pseudo}, the partial signalling solution transfers ownership of monitor \code{B} at lines \ref{line:signal1} to the waiter but does not wake the waiting thread since it is still using monitor \code{A}.
     1643Again using listing \ref{lst:int-bulk-cfa}, the partial signalling solution transfers ownership of monitor @B@ at lines \ref{line:signal1} to the waiter but does not wake the waiting thread since it is still using monitor @A@.
    15491644Only when it reaches line \ref{line:lastRelease} does it actually wake up the waiting thread.
    15501645This solution has the benefit that complexity is encapsulated into only two actions: passing monitors to the next owner when they should be released and conditionally waking threads if all conditions are met.
     
    15541649Using partial signalling, listing \ref{lst:dependency} can be solved easily:
    15551650\begin{itemize}
    1556         \item When thread $\gamma$ reaches line \ref{line:release-ab} it transfers monitor \code{B} to thread $\alpha$ and continues to hold monitor \code{A}.
    1557         \item When thread $\gamma$ reaches line \ref{line:release-a}  it transfers monitor \code{A} to thread $\beta$  and wakes it up.
    1558         \item When thread $\beta$  reaches line \ref{line:release-aa} it transfers monitor \code{A} to thread $\alpha$ and wakes it up.
     1651        \item When thread $\gamma$ reaches line \ref{line:release-ab} it transfers monitor @B@ to thread $\alpha$ and continues to hold monitor @A@.
     1652        \item When thread $\gamma$ reaches line \ref{line:release-a}  it transfers monitor @A@ to thread $\beta$  and wakes it up.
     1653        \item When thread $\beta$  reaches line \ref{line:release-aa} it transfers monitor @A@ to thread $\alpha$ and wakes it up.
    15591654\end{itemize}
    15601655
     
    15661661\begin{table}
    15671662\begin{tabular}{|c|c|}
    1568 \code{signal} & \code{signal_block} \\
     1663@signal@ & @signal_block@ \\
    15691664\hline
    1570 \begin{cfacode}[tabsize=3]
     1665\begin{cfa}[tabsize=3]
    15711666monitor DatingService
    15721667{
    1573         //compatibility codes
     1668        // compatibility codes
    15741669        enum{ CCodes = 20 };
    15751670
     
    15821677condition exchange;
    15831678
    1584 int girl(int phoneNo, int ccode)
     1679int girl(int phoneNo, int cfa)
    15851680{
    1586         //no compatible boy ?
    1587         if(empty(boys[ccode]))
     1681        // no compatible boy ?
     1682        if(empty(boys[cfa]))
    15881683        {
    1589                 //wait for boy
    1590                 wait(girls[ccode]);
    1591 
    1592                 //make phone number available
     1684                // wait for boy
     1685                wait(girls[cfa]);
     1686
     1687                // make phone number available
    15931688                girlPhoneNo = phoneNo;
    15941689
    1595                 //wake boy from chair
     1690                // wake boy from chair
    15961691                signal(exchange);
    15971692        }
    15981693        else
    15991694        {
    1600                 //make phone number available
     1695                // make phone number available
    16011696                girlPhoneNo = phoneNo;
    16021697
    1603                 //wake boy
    1604                 signal(boys[ccode]);
    1605 
    1606                 //sit in chair
     1698                // wake boy
     1699                signal(boys[cfa]);
     1700
     1701                // sit in chair
    16071702                wait(exchange);
    16081703        }
     
    16101705}
    16111706
    1612 int boy(int phoneNo, int ccode)
     1707int boy(int phoneNo, int cfa)
    16131708{
    1614         //same as above
    1615         //with boy/girl interchanged
    1616 }
    1617 \end{cfacode}&\begin{cfacode}[tabsize=3]
     1709        // same as above
     1710        // with boy/girl interchanged
     1711}
     1712\end{cfa}&\begin{cfa}[tabsize=3]
    16181713monitor DatingService
    16191714{
    1620         //compatibility codes
     1715        // compatibility codes
    16211716        enum{ CCodes = 20 };
    16221717
     
    16271722condition girls[CCodes];
    16281723condition boys [CCodes];
    1629 //exchange is not needed
    1630 
    1631 int girl(int phoneNo, int ccode)
     1724// exchange is not needed
     1725
     1726int girl(int phoneNo, int cfa)
    16321727{
    1633         //no compatible boy ?
    1634         if(empty(boys[ccode]))
     1728        // no compatible boy ?
     1729        if(empty(boys[cfa]))
    16351730        {
    1636                 //wait for boy
    1637                 wait(girls[ccode]);
    1638 
    1639                 //make phone number available
     1731                // wait for boy
     1732                wait(girls[cfa]);
     1733
     1734                // make phone number available
    16401735                girlPhoneNo = phoneNo;
    16411736
    1642                 //wake boy from chair
     1737                // wake boy from chair
    16431738                signal(exchange);
    16441739        }
    16451740        else
    16461741        {
    1647                 //make phone number available
     1742                // make phone number available
    16481743                girlPhoneNo = phoneNo;
    16491744
    1650                 //wake boy
    1651                 signal_block(boys[ccode]);
    1652 
    1653                 //second handshake unnecessary
     1745                // wake boy
     1746                signal_block(boys[cfa]);
     1747
     1748                // second handshake unnecessary
    16541749
    16551750        }
     
    16571752}
    16581753
    1659 int boy(int phoneNo, int ccode)
     1754int boy(int phoneNo, int cfa)
    16601755{
    1661         //same as above
    1662         //with boy/girl interchanged
    1663 }
    1664 \end{cfacode}
     1756        // same as above
     1757        // with boy/girl interchanged
     1758}
     1759\end{cfa}
    16651760\end{tabular}
    1666 \caption{Dating service example using \code{signal} and \code{signal_block}. }
     1761\caption{Dating service example using \protect\lstinline|signal| and \protect\lstinline|signal_block|. }
    16671762\label{tbl:datingservice}
    16681763\end{table}
    16691764An important note is that, until now, signalling a monitor was a delayed operation.
    1670 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.
    1671 However, in some cases, it may be more convenient for users to immediately transfer ownership to the thread that is waiting for cooperation, which is achieved using the \code{signal_block} routine.
     1765The ownership of the monitor is transferred only when the monitor would have otherwise been released, not at the point of the @signal@ statement.
     1766However, in some cases, it may be more convenient for users to immediately transfer ownership to the thread that is waiting for cooperation, which is achieved using the @signal_block@ routine.
    16721767
    16731768The example in table \ref{tbl:datingservice} highlights the difference in behaviour.
    1674 As mentioned, \code{signal} only transfers ownership once the current critical section exits; this behaviour requires additional synchronization when a two-way handshake is needed.
    1675 To avoid this explicit synchronization, the \code{condition} type offers the \code{signal_block} routine, which handles the two-way handshake as shown in the example.
     1769As mentioned, @signal@ only transfers ownership once the current critical section exits; this behaviour requires additional synchronization when a two-way handshake is needed.
     1770To avoid this explicit synchronization, the @condition@ type offers the @signal_block@ routine, which handles the two-way handshake as shown in the example.
    16761771This feature removes the need for a second condition variables and simplifies programming.
    1677 Like every other monitor semantic, \code{signal_block} uses barging prevention, which means mutual-exclusion is baton-passed both on the front end and the back end of the call to \code{signal_block}, meaning no other thread can acquire the monitor either before or after the call.
     1772Like every other monitor semantic, @signal_block@ uses barging prevention, which means mutual-exclusion is baton-passed both on the front end and the back end of the call to @signal_block@, meaning no other thread can acquire the monitor either before or after the call.
    16781773
    16791774% ======================================================================
     
    16871782Internal Scheduling & External Scheduling & Go\\
    16881783\hline
    1689 \begin{ucppcode}[tabsize=3]
     1784\begin{uC++}[tabsize=3]
    16901785_Monitor Semaphore {
    16911786        condition c;
     
    17021797        }
    17031798}
    1704 \end{ucppcode}&\begin{ucppcode}[tabsize=3]
     1799\end{uC++}&\begin{uC++}[tabsize=3]
    17051800_Monitor Semaphore {
    17061801
     
    17171812        }
    17181813}
    1719 \end{ucppcode}&\begin{gocode}[tabsize=3]
     1814\end{uC++}&\begin{Go}[tabsize=3]
    17201815type MySem struct {
    17211816        inUse bool
     
    17371832        s.inUse = false
    17381833
    1739         //This actually deadlocks
    1740         //when single thread
     1834        // This actually deadlocks
     1835        // when single thread
    17411836        s.c <- false
    17421837}
    1743 \end{gocode}
     1838\end{Go}
    17441839\end{tabular}
    17451840\caption{Different forms of scheduling.}
     
    17481843This method is more constrained and explicit, which helps users reduce the non-deterministic nature of concurrency.
    17491844Indeed, as the following examples demonstrate, external scheduling allows users to wait for events from other threads without the concern of unrelated events occurring.
    1750 External scheduling can generally be done either in terms of control flow (e.g., Ada with \code{accept}, \uC with \code{_Accept}) or in terms of data (e.g., Go with channels).
     1845External scheduling can generally be done either in terms of control flow (e.g., Ada with @accept@, \uC with @_Accept@) or in terms of data (e.g., Go with channels).
    17511846Of course, both of these paradigms have their own strengths and weaknesses, but for this project, control-flow semantics was chosen to stay consistent with the rest of the languages semantics.
    17521847Two challenges specific to \CFA arise when trying to add external scheduling with loose object definitions and multiple-monitor routines.
    1753 The previous example shows a simple use \code{_Accept} versus \code{wait}/\code{signal} and its advantages.
    1754 Note that while other languages often use \code{accept}/\code{select} as the core external scheduling keyword, \CFA uses \code{waitfor} to prevent name collisions with existing socket \textbf{api}s.
    1755 
    1756 For the \code{P} member above using internal scheduling, the call to \code{wait} only guarantees that \code{V} is the last routine to access the monitor, allowing a third routine, say \code{isInUse()}, acquire mutual exclusion several times while routine \code{P} is waiting.
    1757 On the other hand, external scheduling guarantees that while routine \code{P} is waiting, no other routine than \code{V} can acquire the monitor.
     1848The previous example shows a simple use @_Accept@ versus @wait@/@signal@ and its advantages.
     1849Note that while other languages often use @accept@/@select@ as the core external scheduling keyword, \CFA uses @waitfor@ to prevent name collisions with existing socket \textbf{api}s.
     1850
     1851For the @P@ member above using internal scheduling, the call to @wait@ only guarantees that @V@ is the last routine to access the monitor, allowing a third routine, say @isInUse()@, acquire mutual exclusion several times while routine @P@ is waiting.
     1852On the other hand, external scheduling guarantees that while routine @P@ is waiting, no other routine than @V@ can acquire the monitor.
    17581853
    17591854% ======================================================================
     
    17651860Since \CFA is not object oriented, monitors become both more difficult to implement and less clear for a user:
    17661861
    1767 \begin{cfacode}
     1862\begin{cfa}
    17681863monitor A {};
    17691864
    17701865void f(A & mutex a);
    17711866void g(A & mutex a) {
    1772         waitfor(f); //Obvious which f() to wait for
    1773 }
    1774 
    1775 void f(A & mutex a, int); //New different F added in scope
     1867        waitfor(f); // Obvious which f() to wait for
     1868}
     1869
     1870void f(A & mutex a, int); // New different F added in scope
    17761871void h(A & mutex a) {
    1777         waitfor(f); //Less obvious which f() to wait for
    1778 }
    1779 \end{cfacode}
     1872        waitfor(f); // Less obvious which f() to wait for
     1873}
     1874\end{cfa}
    17801875
    17811876Furthermore, external scheduling is an example where implementation constraints become visible from the interface.
    1782 Here is the pseudo-code for the entering phase of a monitor:
     1877Here is the cfa-code for the entering phase of a monitor:
    17831878\begin{center}
    17841879\begin{tabular}{l}
    1785 \begin{pseudo}
     1880\begin{cfa}
    17861881        if monitor is free
    17871882                enter
     
    17921887        else
    17931888                block
    1794 \end{pseudo}
     1889\end{cfa}
    17951890\end{tabular}
    17961891\end{center}
    17971892For the first two conditions, it is easy to implement a check that can evaluate the condition in a few instructions.
    1798 However, a fast check for \pscode{monitor accepts me} is much harder to implement depending on the constraints put on the monitors.
     1893However, a fast check for @monitor accepts me@ is much harder to implement depending on the constraints put on the monitors.
    17991894Indeed, monitors are often expressed as an entry queue and some acceptor queue as in Figure~\ref{fig:ClassicalMonitor}.
    18001895
     
    18221917The alternative is to alter the implementation as in Figure~\ref{fig:BulkMonitor}.
    18231918Here, the mutex routine called is associated with a thread on the entry queue while a list of acceptable routines is kept separate.
    1824 Generating a mask dynamically means that the storage for the mask information can vary between calls to \code{waitfor}, allowing for more flexibility and extensions.
     1919Generating a mask dynamically means that the storage for the mask information can vary between calls to @waitfor@, allowing for more flexibility and extensions.
    18251920Storing an array of accepted function pointers replaces the single instruction bitmask comparison with dereferencing a pointer followed by a linear search.
    1826 Furthermore, supporting nested external scheduling (e.g., listing \ref{lst:nest-ext}) may now require additional searches for the \code{waitfor} statement to check if a routine is already queued.
     1921Furthermore, supporting nested external scheduling (e.g., listing \ref{lst:nest-ext}) may now require additional searches for the @waitfor@ statement to check if a routine is already queued.
    18271922
    18281923\begin{figure}
    1829 \begin{cfacode}[caption={Example of nested external scheduling},label={lst:nest-ext}]
     1924\begin{cfa}[caption={Example of nested external scheduling},label={lst:nest-ext}]
    18301925monitor M {};
    18311926void foo( M & mutex a ) {}
    18321927void bar( M & mutex b ) {
    1833         //Nested in the waitfor(bar, c) call
     1928        // Nested in the waitfor(bar, c) call
    18341929        waitfor(foo, b);
    18351930}
     
    18381933}
    18391934
    1840 \end{cfacode}
     1935\end{cfa}
    18411936\end{figure}
    18421937
     
    18581953External scheduling, like internal scheduling, becomes significantly more complex when introducing multi-monitor syntax.
    18591954Even in the simplest possible case, some new semantics needs to be established:
    1860 \begin{cfacode}
     1955\begin{cfa}
    18611956monitor M {};
    18621957
     
    18641959
    18651960void g(M & mutex b, M & mutex c) {
    1866         waitfor(f); //two monitors M => unknown which to pass to f(M & mutex)
    1867 }
    1868 \end{cfacode}
     1961        waitfor(f); // two monitors M => unknown which to pass to f(M & mutex)
     1962}
     1963\end{cfa}
    18691964The obvious solution is to specify the correct monitor as follows:
    18701965
    1871 \begin{cfacode}
     1966\begin{cfa}
    18721967monitor M {};
    18731968
     
    18751970
    18761971void g(M & mutex a, M & mutex b) {
    1877         //wait for call to f with argument b
     1972        // wait for call to f with argument b
    18781973        waitfor(f, b);
    18791974}
    1880 \end{cfacode}
     1975\end{cfa}
    18811976This syntax is unambiguous.
    1882 Both locks are acquired and kept by \code{g}.
    1883 When routine \code{f} is called, the lock for monitor \code{b} is temporarily transferred from \code{g} to \code{f} (while \code{g} still holds lock \code{a}).
    1884 This behaviour can be extended to the multi-monitor \code{waitfor} statement as follows.
    1885 
    1886 \begin{cfacode}
     1977Both locks are acquired and kept by @g@.
     1978When routine @f@ is called, the lock for monitor @b@ is temporarily transferred from @g@ to @f@ (while @g@ still holds lock @a@).
     1979This behaviour can be extended to the multi-monitor @waitfor@ statement as follows.
     1980
     1981\begin{cfa}
    18871982monitor M {};
    18881983
     
    18901985
    18911986void g(M & mutex a, M & mutex b) {
    1892         //wait for call to f with arguments a and b
     1987        // wait for call to f with arguments a and b
    18931988        waitfor(f, a, b);
    18941989}
    1895 \end{cfacode}
    1896 
    1897 Note that the set of monitors passed to the \code{waitfor} statement must be entirely contained in the set of monitors already acquired in the routine. \code{waitfor} used in any other context is undefined behaviour.
     1990\end{cfa}
     1991
     1992Note that the set of monitors passed to the @waitfor@ statement must be entirely contained in the set of monitors already acquired in the routine. @waitfor@ used in any other context is undefined behaviour.
    18981993
    18991994An important behaviour to note is when a set of monitors only match partially:
    19001995
    1901 \begin{cfacode}
     1996\begin{cfa}
    19021997mutex struct A {};
    19031998
     
    19122007
    19132008void foo() {
    1914         g(a1, b); //block on accept
     2009        g(a1, b); // block on accept
    19152010}
    19162011
    19172012void bar() {
    1918         f(a2, b); //fulfill cooperation
    1919 }
    1920 \end{cfacode}
     2013        f(a2, b); // fulfill cooperation
     2014}
     2015\end{cfa}
    19212016While the equivalent can happen when using internal scheduling, the fact that conditions are specific to a set of monitors means that users have to use two different condition variables.
    19222017In both cases, partially matching monitor sets does not wakeup the waiting thread.
    1923 It is also important to note that in the case of external scheduling the order of parameters is irrelevant; \code{waitfor(f,a,b)} and \code{waitfor(f,b,a)} are indistinguishable waiting condition.
    1924 
    1925 % ======================================================================
    1926 % ======================================================================
    1927 \subsection{\code{waitfor} Semantics}
    1928 % ======================================================================
    1929 % ======================================================================
    1930 
    1931 Syntactically, the \code{waitfor} statement takes a function identifier and a set of monitors.
    1932 While the set of monitors can be any list of expressions, the function name is more restricted because the compiler validates at compile time the validity of the function type and the parameters used with the \code{waitfor} statement.
     2018It is also important to note that in the case of external scheduling the order of parameters is irrelevant; @waitfor(f,a,b)@ and @waitfor(f,b,a)@ are indistinguishable waiting condition.
     2019
     2020% ======================================================================
     2021% ======================================================================
     2022\subsection{\protect\lstinline|waitfor| Semantics}
     2023% ======================================================================
     2024% ======================================================================
     2025
     2026Syntactically, the @waitfor@ statement takes a function identifier and a set of monitors.
     2027While the set of monitors can be any list of expressions, the function name is more restricted because the compiler validates at compile time the validity of the function type and the parameters used with the @waitfor@ statement.
    19332028It checks that the set of monitors passed in matches the requirements for a function call.
    19342029Listing \ref{lst:waitfor} shows various usages of the waitfor statement and which are acceptable.
    1935 The choice of the function type is made ignoring any non-\code{mutex} parameter.
     2030The choice of the function type is made ignoring any non-@mutex@ parameter.
    19362031One limitation of the current implementation is that it does not handle overloading, but overloading is possible.
    19372032\begin{figure}
    1938 \begin{cfacode}[caption={Various correct and incorrect uses of the waitfor statement},label={lst:waitfor}]
     2033\begin{cfa}[caption={Various correct and incorrect uses of the waitfor statement},label={lst:waitfor}]
    19392034monitor A{};
    19402035monitor B{};
     
    19502045        void (*fp)( A & mutex ) = f1;
    19512046
    1952         waitfor(f1, a1);     //Correct : 1 monitor case
    1953         waitfor(f2, a1, b1); //Correct : 2 monitor case
    1954         waitfor(f3, a1);     //Correct : non-mutex arguments are ignored
    1955         waitfor(f1, *ap);    //Correct : expression as argument
    1956 
    1957         waitfor(f1, a1, b1); //Incorrect : Too many mutex arguments
    1958         waitfor(f2, a1);     //Incorrect : Too few mutex arguments
    1959         waitfor(f2, a1, a2); //Incorrect : Mutex arguments don't match
    1960         waitfor(f1, 1);      //Incorrect : 1 not a mutex argument
    1961         waitfor(f9, a1);     //Incorrect : f9 function does not exist
    1962         waitfor(*fp, a1 );   //Incorrect : fp not an identifier
    1963         waitfor(f4, a1);     //Incorrect : f4 ambiguous
    1964 
    1965         waitfor(f2, a1, b2); //Undefined behaviour : b2 not mutex
    1966 }
    1967 \end{cfacode}
     2047        waitfor(f1, a1);     // Correct : 1 monitor case
     2048        waitfor(f2, a1, b1); // Correct : 2 monitor case
     2049        waitfor(f3, a1);     // Correct : non-mutex arguments are ignored
     2050        waitfor(f1, *ap);    // Correct : expression as argument
     2051
     2052        waitfor(f1, a1, b1); // Incorrect : Too many mutex arguments
     2053        waitfor(f2, a1);     // Incorrect : Too few mutex arguments
     2054        waitfor(f2, a1, a2); // Incorrect : Mutex arguments don't match
     2055        waitfor(f1, 1);      // Incorrect : 1 not a mutex argument
     2056        waitfor(f9, a1);     // Incorrect : f9 function does not exist
     2057        waitfor(*fp, a1 );   // Incorrect : fp not an identifier
     2058        waitfor(f4, a1);     // Incorrect : f4 ambiguous
     2059
     2060        waitfor(f2, a1, b2); // Undefined behaviour : b2 not mutex
     2061}
     2062\end{cfa}
    19682063\end{figure}
    19692064
    1970 Finally, for added flexibility, \CFA supports constructing a complex \code{waitfor} statement using the \code{or}, \code{timeout} and \code{else}.
    1971 Indeed, multiple \code{waitfor} clauses can be chained together using \code{or}; this chain forms a single statement that uses baton pass to any function that fits one of the function+monitor set passed in.
    1972 To enable users to tell which accepted function executed, \code{waitfor}s are followed by a statement (including the null statement \code{;}) or a compound statement, which is executed after the clause is triggered.
    1973 A \code{waitfor} chain can also be followed by a \code{timeout}, to signify an upper bound on the wait, or an \code{else}, to signify that the call should be non-blocking, which checks for a matching function call already arrived and otherwise continues.
    1974 Any and all of these clauses can be preceded by a \code{when} condition to dynamically toggle the accept clauses on or off based on some current state.
     2065Finally, for added flexibility, \CFA supports constructing a complex @waitfor@ statement using the @or@, @timeout@ and @else@.
     2066Indeed, multiple @waitfor@ clauses can be chained together using @or@; this chain forms a single statement that uses baton pass to any function that fits one of the function+monitor set passed in.
     2067To enable users to tell which accepted function executed, @waitfor@s are followed by a statement (including the null statement @;@) or a compound statement, which is executed after the clause is triggered.
     2068A @waitfor@ chain can also be followed by a @timeout@, to signify an upper bound on the wait, or an @else@, to signify that the call should be non-blocking, which checks for a matching function call already arrived and otherwise continues.
     2069Any and all of these clauses can be preceded by a @when@ condition to dynamically toggle the accept clauses on or off based on some current state.
    19752070Listing \ref{lst:waitfor2} demonstrates several complex masks and some incorrect ones.
    19762071
    19772072\begin{figure}
    1978 \begin{cfacode}[caption={Various correct and incorrect uses of the or, else, and timeout clause around a waitfor statement},label={lst:waitfor2}]
     2073\begin{cfa}[caption={Various correct and incorrect uses of the or, else, and timeout clause around a waitfor statement},label={lst:waitfor2}]
    19792074monitor A{};
    19802075
     
    19832078
    19842079void foo( A & mutex a, bool b, int t ) {
    1985         //Correct : blocking case
     2080        // Correct : blocking case
    19862081        waitfor(f1, a);
    19872082
    1988         //Correct : block with statement
     2083        // Correct : block with statement
    19892084        waitfor(f1, a) {
    19902085                sout | "f1" | endl;
    19912086        }
    19922087
    1993         //Correct : block waiting for f1 or f2
     2088        // Correct : block waiting for f1 or f2
    19942089        waitfor(f1, a) {
    19952090                sout | "f1" | endl;
     
    19982093        }
    19992094
    2000         //Correct : non-blocking case
     2095        // Correct : non-blocking case
    20012096        waitfor(f1, a); or else;
    20022097
    2003         //Correct : non-blocking case
     2098        // Correct : non-blocking case
    20042099        waitfor(f1, a) {
    20052100                sout | "blocked" | endl;
     
    20082103        }
    20092104
    2010         //Correct : block at most 10 seconds
     2105        // Correct : block at most 10 seconds
    20112106        waitfor(f1, a) {
    20122107                sout | "blocked" | endl;
     
    20152110        }
    20162111
    2017         //Correct : block only if b == true
    2018         //if b == false, don't even make the call
     2112        // Correct : block only if b == true
     2113        // if b == false, don't even make the call
    20192114        when(b) waitfor(f1, a);
    20202115
    2021         //Correct : block only if b == true
    2022         //if b == false, make non-blocking call
     2116        // Correct : block only if b == true
     2117        // if b == false, make non-blocking call
    20232118        waitfor(f1, a); or when(!b) else;
    20242119
    2025         //Correct : block only of t > 1
     2120        // Correct : block only of t > 1
    20262121        waitfor(f1, a); or when(t > 1) timeout(t); or else;
    20272122
    2028         //Incorrect : timeout clause is dead code
     2123        // Incorrect : timeout clause is dead code
    20292124        waitfor(f1, a); or timeout(t); or else;
    20302125
    2031         //Incorrect : order must be
    2032         //waitfor [or waitfor... [or timeout] [or else]]
     2126        // Incorrect : order must be
     2127        // waitfor [or waitfor... [or timeout] [or else]]
    20332128        timeout(t); or waitfor(f1, a); or else;
    20342129}
    2035 \end{cfacode}
     2130\end{cfa}
    20362131\end{figure}
    20372132
     
    20412136% ======================================================================
    20422137% ======================================================================
    2043 An interesting use for the \code{waitfor} statement is destructor semantics.
    2044 Indeed, the \code{waitfor} statement can accept any \code{mutex} routine, which includes the destructor (see section \ref{data}).
     2138An interesting use for the @waitfor@ statement is destructor semantics.
     2139Indeed, the @waitfor@ statement can accept any @mutex@ routine, which includes the destructor (see section \ref{data}).
    20452140However, with the semantics discussed until now, waiting for the destructor does not make any sense, since using an object after its destructor is called is undefined behaviour.
    2046 The simplest approach is to disallow \code{waitfor} on a destructor.
    2047 However, a more expressive approach is to flip ordering of execution when waiting for the destructor, meaning that waiting for the destructor allows the destructor to run after the current \code{mutex} routine, similarly to how a condition is signalled.
     2141The simplest approach is to disallow @waitfor@ on a destructor.
     2142However, a more expressive approach is to flip ordering of execution when waiting for the destructor, meaning that waiting for the destructor allows the destructor to run after the current @mutex@ routine, similarly to how a condition is signalled.
    20482143\begin{figure}
    2049 \begin{cfacode}[caption={Example of an executor which executes action in series until the destructor is called.},label={lst:dtor-order}]
     2144\begin{cfa}[caption={Example of an executor which executes action in series until the destructor is called.},label={lst:dtor-order}]
    20502145monitor Executer {};
    20512146struct  Action;
     
    20612156        }
    20622157}
    2063 \end{cfacode}
     2158\end{cfa}
    20642159\end{figure}
    20652160For example, listing \ref{lst:dtor-order} shows an example of an executor with an infinite loop, which waits for the destructor to break out of this loop.
     
    20792174In this decade, it is no longer reasonable to create a high-performance application without caring about parallelism.
    20802175Indeed, parallelism is an important aspect of performance and more specifically throughput and hardware utilization.
    2081 The lowest-level approach of parallelism is to use \textbf{kthread} in combination with semantics like \code{fork}, \code{join}, etc.
     2176The lowest-level approach of parallelism is to use \textbf{kthread} in combination with semantics like @fork@, @join@, etc.
    20822177However, since these have significant costs and limitations, \textbf{kthread} are now mostly used as an implementation tool rather than a user oriented one.
    20832178There are several alternatives to solve these issues that all have strengths and weaknesses.
     
    21582253Conveniently, the call stack fits that description and is easy to use, which is why it is used heavily in the implementation of internal scheduling, particularly variable-length arrays.
    21592254Since stack allocation is based on scopes, the first step of the implementation is to identify the scopes that are available to store the information, and which of these can have a variable-length array.
    2160 The threads and the condition both have a fixed amount of memory, while \code{mutex} routines and blocking calls allow for an unbound amount, within the stack size.
     2255The threads and the condition both have a fixed amount of memory, while @mutex@ routines and blocking calls allow for an unbound amount, within the stack size.
    21612256
    21622257Note that since the major contributions of this paper are extending monitor semantics to \textbf{bulk-acq} and loose object definitions, any challenges that are not resulting of these characteristics of \CFA are considered as solved problems and therefore not discussed.
     
    21682263% ======================================================================
    21692264
    2170 The first step towards the monitor implementation is simple \code{mutex} routines.
     2265The first step towards the monitor implementation is simple @mutex@ routines.
    21712266In the single monitor case, mutual-exclusion is done using the entry/exit procedure in listing \ref{lst:entry1}.
    21722267The entry/exit procedures do not have to be extended to support multiple monitors.
     
    21792274\begin{multicols}{2}
    21802275Entry
    2181 \begin{pseudo}
     2276\begin{cfa}
    21822277if monitor is free
    21832278        enter
     
    21872282        block
    21882283increment recursions
    2189 \end{pseudo}
     2284\end{cfa}
    21902285\columnbreak
    21912286Exit
    2192 \begin{pseudo}
     2287\begin{cfa}
    21932288decrement recursion
    21942289if recursion == 0
    21952290        if entry queue not empty
    21962291                wake-up thread
    2197 \end{pseudo}
     2292\end{cfa}
    21982293\end{multicols}
    2199 \begin{pseudo}[caption={Initial entry and exit routine for monitors},label={lst:entry1}]
    2200 \end{pseudo}
     2294\begin{cfa}[caption={Initial entry and exit routine for monitors},label={lst:entry1}]
     2295\end{cfa}
    22012296\end{figure}
    22022297
     
    22052300However, it is shown that entry-point locking solves most of the issues.
    22062301
    2207 First of all, interaction between \code{otype} polymorphism (see Section~\ref{s:ParametricPolymorphism}) and monitors is impossible since monitors do not support copying.
    2208 Therefore, the main question is how to support \code{dtype} polymorphism.
     2302First of all, interaction between @otype@ polymorphism (see Section~\ref{s:ParametricPolymorphism}) and monitors is impossible since monitors do not support copying.
     2303Therefore, the main question is how to support @dtype@ polymorphism.
    22092304It is important to present the difference between the two acquiring options: \textbf{callsite-locking} and entry-point locking, i.e., acquiring the monitors before making a mutex routine-call or as the first operation of the mutex routine-call.
    22102305For example:
     
    22132308\begin{tabular}{|c|c|c|}
    22142309Mutex & \textbf{callsite-locking} & \textbf{entry-point-locking} \\
    2215 call & pseudo-code & pseudo-code \\
     2310call & cfa-code & cfa-code \\
    22162311\hline
    2217 \begin{cfacode}[tabsize=3]
     2312\begin{cfa}[tabsize=3]
    22182313void foo(monitor& mutex a){
    22192314
    2220         //Do Work
     2315        // Do Work
    22212316        //...
    22222317
     
    22292324
    22302325}
    2231 \end{cfacode} & \begin{pseudo}[tabsize=3]
     2326\end{cfa} & \begin{cfa}[tabsize=3]
    22322327foo(& a) {
    22332328
    2234         //Do Work
     2329        // Do Work
    22352330        //...
    22362331
     
    22432338        release(a);
    22442339}
    2245 \end{pseudo} & \begin{pseudo}[tabsize=3]
     2340\end{cfa} & \begin{cfa}[tabsize=3]
    22462341foo(& a) {
    22472342        acquire(a);
    2248         //Do Work
     2343        // Do Work
    22492344        //...
    22502345        release(a);
     
    22572352
    22582353}
    2259 \end{pseudo}
     2354\end{cfa}
    22602355\end{tabular}
    22612356\end{center}
     
    22642359\end{table}
    22652360
    2266 Note the \code{mutex} keyword relies on the type system, which means that in cases where a generic monitor-routine is desired, writing the mutex routine is possible with the proper trait, e.g.:
    2267 \begin{cfacode}
    2268 //Incorrect: T may not be monitor
     2361Note the @mutex@ keyword relies on the type system, which means that in cases where a generic monitor-routine is desired, writing the mutex routine is possible with the proper trait, e.g.:
     2362\begin{cfa}
     2363// Incorrect: T may not be monitor
    22692364forall(dtype T)
    22702365void foo(T * mutex t);
    22712366
    2272 //Correct: this function only works on monitors (any monitor)
     2367// Correct: this function only works on monitors (any monitor)
    22732368forall(dtype T | is_monitor(T))
    22742369void bar(T * mutex t));
    2275 \end{cfacode}
     2370\end{cfa}
    22762371
    22772372Both entry point and \textbf{callsite-locking} are feasible implementations.
     
    23232418Obviously, this doubles the context-switch cost because threads must context-switch to an intermediate stack.
    23242419The alternative 1-step context-switch uses the stack of the ``from'' thread to schedule and then context-switches directly to the ``to'' thread.
    2325 However, the performance of the 2-step context-switch is still superior to a \code{pthread_yield} (see section \ref{results}).
    2326 Additionally, for users in need for optimal performance, it is important to note that having a 2-step context-switch as the default does not prevent \CFA from offering a 1-step context-switch (akin to the Microsoft \code{SwitchToFiber}~\cite{switchToWindows} routine).
     2420However, the performance of the 2-step context-switch is still superior to a @pthread_yield@ (see section \ref{results}).
     2421Additionally, for users in need for optimal performance, it is important to note that having a 2-step context-switch as the default does not prevent \CFA from offering a 1-step context-switch (akin to the Microsoft @SwitchToFiber@~\cite{switchToWindows} routine).
    23272422This option is not currently present in \CFA, but the changes required to add it are strictly additive.
    23282423
     
    23562451This behaviour is only a problem if all kernel threads, among which a user thread can migrate, differ in terms of signal masks\footnote{Sadly, official POSIX documentation is silent on what distinguishes ``async-signal-safe'' functions from other functions.}.
    23572452However, since the kernel thread handling preemption requires a different signal mask, executing user threads on the kernel-alarm thread can cause deadlocks.
    2358 For this reason, the alarm thread is in a tight loop around a system call to \code{sigwaitinfo}, requiring very little CPU time for preemption.
     2453For this reason, the alarm thread is in a tight loop around a system call to @sigwaitinfo@, requiring very little CPU time for preemption.
    23592454One final detail about the alarm thread is how to wake it when additional communication is required (e.g., on thread termination).
    2360 This unblocking is also done using {\tt SIGALRM}, but sent through the \code{pthread_sigqueue}.
    2361 Indeed, \code{sigwait} can differentiate signals sent from \code{pthread_sigqueue} from signals sent from alarms or the kernel.
     2455This unblocking is also done using {\tt SIGALRM}, but sent through the @pthread_sigqueue@.
     2456Indeed, @sigwait@ can differentiate signals sent from @pthread_sigqueue@ from signals sent from alarms or the kernel.
    23622457
    23632458\subsection{Scheduler}
     
    24052500\begin{multicols}{2}
    24062501Entry
    2407 \begin{pseudo}
     2502\begin{cfa}
    24082503if monitor is free
    24092504        enter
     
    24142509increment recursion
    24152510
    2416 \end{pseudo}
     2511\end{cfa}
    24172512\columnbreak
    24182513Exit
    2419 \begin{pseudo}
     2514\begin{cfa}
    24202515decrement recursion
    24212516if recursion == 0
     
    24272522        if entry queue not empty
    24282523                wake-up thread
    2429 \end{pseudo}
     2524\end{cfa}
    24302525\end{multicols}
    2431 \begin{pseudo}[caption={Entry and exit routine for monitors with internal scheduling},label={lst:entry2}]
    2432 \end{pseudo}
     2526\begin{cfa}[caption={Entry and exit routine for monitors with internal scheduling},label={lst:entry2}]
     2527\end{cfa}
    24332528\end{figure}
    24342529
     
    24362531Basically, the solution boils down to having a separate data structure for the condition queue and the AS-stack, and unconditionally transferring ownership of the monitors but only unblocking the thread when the last monitor has transferred ownership.
    24372532This solution is deadlock safe as well as preventing any potential barging.
    2438 The data structures used for the AS-stack are reused extensively for external scheduling, but in the case of internal scheduling, the data is allocated using variable-length arrays on the call stack of the \code{wait} and \code{signal_block} routines.
     2533The data structures used for the AS-stack are reused extensively for external scheduling, but in the case of internal scheduling, the data is allocated using variable-length arrays on the call stack of the @wait@ and @signal_block@ routines.
    24392534
    24402535\begin{figure}[H]
     
    24482543Figure \ref{fig:structs} shows a high-level representation of these data structures.
    24492544The main idea behind them is that, a thread cannot contain an arbitrary number of intrusive ``next'' pointers for linking onto monitors.
    2450 The \code{condition node} is the data structure that is queued onto a condition variable and, when signalled, the condition queue is popped and each \code{condition criterion} is moved to the AS-stack.
     2545The @condition node@ is the data structure that is queued onto a condition variable and, when signalled, the condition queue is popped and each @condition criterion@ is moved to the AS-stack.
    24512546Once all the criteria have been popped from their respective AS-stacks, the thread is woken up, which is what is shown in listing \ref{lst:entry2}.
    24522547
     
    24582553Similarly to internal scheduling, external scheduling for multiple monitors relies on the idea that waiting-thread queues are no longer specific to a single monitor, as mentioned in section \ref{extsched}.
    24592554For internal scheduling, these queues are part of condition variables, which are still unique for a given scheduling operation (i.e., no signal statement uses multiple conditions).
    2460 However, in the case of external scheduling, there is no equivalent object which is associated with \code{waitfor} statements.
     2555However, in the case of external scheduling, there is no equivalent object which is associated with @waitfor@ statements.
    24612556This absence means the queues holding the waiting threads must be stored inside at least one of the monitors that is acquired.
    2462 These monitors being the only objects that have sufficient lifetime and are available on both sides of the \code{waitfor} statement.
     2557These monitors being the only objects that have sufficient lifetime and are available on both sides of the @waitfor@ statement.
    24632558This requires an algorithm to choose which monitor holds the relevant queue.
    24642559It is also important that said algorithm be independent of the order in which users list parameters.
     
    24772572\begin{itemize}
    24782573        \item The threads waiting on the entry queue need to keep track of which routine they are trying to enter, and using which set of monitors.
    2479 The \code{mutex} routine already has all the required information on its stack, so the thread only needs to keep a pointer to that information.
     2574The @mutex@ routine already has all the required information on its stack, so the thread only needs to keep a pointer to that information.
    24802575        \item The monitors need to keep a mask of acceptable routines.
    24812576This mask contains for each acceptable routine, a routine pointer and an array of monitors to go with it.
    24822577It also needs storage to keep track of which routine was accepted.
    24832578Since this information is not specific to any monitor, the monitors actually contain a pointer to an integer on the stack of the waiting thread.
    2484 Note that if a thread has acquired two monitors but executes a \code{waitfor} with only one monitor as a parameter, setting the mask of acceptable routines to both monitors will not cause any problems since the extra monitor will not change ownership regardless.
    2485 This becomes relevant when \code{when} clauses affect the number of monitors passed to a \code{waitfor} statement.
     2579Note that if a thread has acquired two monitors but executes a @waitfor@ with only one monitor as a parameter, setting the mask of acceptable routines to both monitors will not cause any problems since the extra monitor will not change ownership regardless.
     2580This becomes relevant when @when@ clauses affect the number of monitors passed to a @waitfor@ statement.
    24862581        \item The entry/exit routines need to be updated as shown in listing \ref{lst:entry3}.
    24872582\end{itemize}
     
    24912586This routine is needed because of the storage requirements of the call order inversion.
    24922587Indeed, when waiting for the destructors, storage is needed for the waiting context and the lifetime of said storage needs to outlive the waiting operation it is needed for.
    2493 For regular \code{waitfor} statements, the call stack of the routine itself matches this requirement but it is no longer the case when waiting for the destructor since it is pushed on to the AS-stack for later.
    2494 The \code{waitfor} semantics can then be adjusted correspondingly, as seen in listing \ref{lst:entry-dtor}
     2588For regular @waitfor@ statements, the call stack of the routine itself matches this requirement but it is no longer the case when waiting for the destructor since it is pushed on to the AS-stack for later.
     2589The @waitfor@ semantics can then be adjusted correspondingly, as seen in listing \ref{lst:entry-dtor}
    24952590
    24962591\begin{figure}
    24972592\begin{multicols}{2}
    24982593Entry
    2499 \begin{pseudo}
     2594\begin{cfa}
    25002595if monitor is free
    25012596        enter
     
    25082603        block
    25092604increment recursion
    2510 \end{pseudo}
     2605\end{cfa}
    25112606\columnbreak
    25122607Exit
    2513 \begin{pseudo}
     2608\begin{cfa}
    25142609decrement recursion
    25152610if recursion == 0
     
    25242619                wake-up thread
    25252620        endif
    2526 \end{pseudo}
     2621\end{cfa}
    25272622\end{multicols}
    2528 \begin{pseudo}[caption={Entry and exit routine for monitors with internal scheduling and external scheduling},label={lst:entry3}]
    2529 \end{pseudo}
     2623\begin{cfa}[caption={Entry and exit routine for monitors with internal scheduling and external scheduling},label={lst:entry3}]
     2624\end{cfa}
    25302625\end{figure}
    25312626
     
    25332628\begin{multicols}{2}
    25342629Destructor Entry
    2535 \begin{pseudo}
     2630\begin{cfa}
    25362631if monitor is free
    25372632        enter
     
    25472642        wait
    25482643increment recursion
    2549 \end{pseudo}
     2644\end{cfa}
    25502645\columnbreak
    25512646Waitfor
    2552 \begin{pseudo}
     2647\begin{cfa}
    25532648if matching thread is already there
    25542649        if found destructor
     
    25702665block
    25712666return
    2572 \end{pseudo}
     2667\end{cfa}
    25732668\end{multicols}
    2574 \begin{pseudo}[caption={Pseudo code for the \code{waitfor} routine and the \code{mutex} entry routine for destructors},label={lst:entry-dtor}]
    2575 \end{pseudo}
     2669\begin{cfa}[caption={Pseudo code for the \protect\lstinline|waitfor| routine and the \protect\lstinline|mutex| entry routine for destructors},label={lst:entry-dtor}]
     2670\end{cfa}
    25762671\end{figure}
    25772672
     
    25852680
    25862681\section{Threads As Monitors}
    2587 As it was subtly alluded in section \ref{threads}, \code{thread}s in \CFA are in fact monitors, which means that all monitor features are available when using threads.
     2682As it was subtly alluded in section \ref{threads}, @thread@s in \CFA are in fact monitors, which means that all monitor features are available when using threads.
    25882683For example, here is a very simple two thread pipeline that could be used for a simulator of a game engine:
    25892684\begin{figure}[H]
    2590 \begin{cfacode}[caption={Toy simulator using \code{thread}s and \code{monitor}s.},label={lst:engine-v1}]
     2685\begin{cfa}[caption={Toy simulator using \protect\lstinline|thread|s and \protect\lstinline|monitor|s.},label={lst:engine-v1}]
    25912686// Visualization declaration
    25922687thread Renderer {} renderer;
     
    26152710        }
    26162711}
    2617 \end{cfacode}
     2712\end{cfa}
    26182713\end{figure}
    26192714One of the obvious complaints of the previous code snippet (other than its toy-like simplicity) is that it does not handle exit conditions and just goes on forever.
    26202715Luckily, the monitor semantics can also be used to clearly enforce a shutdown order in a concise manner:
    26212716\begin{figure}[H]
    2622 \begin{cfacode}[caption={Same toy simulator with proper termination condition.},label={lst:engine-v2}]
     2717\begin{cfa}[caption={Same toy simulator with proper termination condition.},label={lst:engine-v2}]
    26232718// Visualization declaration
    26242719thread Renderer {} renderer;
     
    26582753// Call destructor for simulator once simulator finishes
    26592754// Call destructor for renderer to signify shutdown
    2660 \end{cfacode}
     2755\end{cfa}
    26612756\end{figure}
    26622757
     
    26642759As mentioned in section \ref{preemption}, \CFA uses preemptive threads by default but can use fibers on demand.
    26652760Currently, using fibers is done by adding the following line of code to the program~:
    2666 \begin{cfacode}
     2761\begin{cfa}
    26672762unsigned int default_preemption() {
    26682763        return 0;
    26692764}
    2670 \end{cfacode}
     2765\end{cfa}
    26712766This function is called by the kernel to fetch the default preemption rate, where 0 signifies an infinite time-slice, i.e., no preemption.
    26722767However, once clusters are fully implemented, it will be possible to create fibers and \textbf{uthread} in the same system, as in listing \ref{lst:fiber-uthread}
    26732768\begin{figure}
    2674 \begin{cfacode}[caption={Using fibers and \textbf{uthread} side-by-side in \CFA},label={lst:fiber-uthread}]
    2675 //Cluster forward declaration
     2769\begin{cfa}[caption={Using fibers and \textbf{uthread} side-by-side in \CFA},label={lst:fiber-uthread}]
     2770// Cluster forward declaration
    26762771struct cluster;
    26772772
    2678 //Processor forward declaration
     2773// Processor forward declaration
    26792774struct processor;
    26802775
    2681 //Construct clusters with a preemption rate
     2776// Construct clusters with a preemption rate
    26822777void ?{}(cluster& this, unsigned int rate);
    2683 //Construct processor and add it to cluster
     2778// Construct processor and add it to cluster
    26842779void ?{}(processor& this, cluster& cluster);
    2685 //Construct thread and schedule it on cluster
     2780// Construct thread and schedule it on cluster
    26862781void ?{}(thread& this, cluster& cluster);
    26872782
    2688 //Declare two clusters
    2689 cluster thread_cluster = { 10`ms };                     //Preempt every 10 ms
    2690 cluster fibers_cluster = { 0 };                         //Never preempt
    2691 
    2692 //Construct 4 processors
     2783// Declare two clusters
     2784cluster thread_cluster = { 10`ms };                     // Preempt every 10 ms
     2785cluster fibers_cluster = { 0 };                         // Never preempt
     2786
     2787// Construct 4 processors
    26932788processor processors[4] = {
    26942789        //2 for the thread cluster
     
    27002795};
    27012796
    2702 //Declares thread
     2797// Declares thread
    27032798thread UThread {};
    27042799void ?{}(UThread& this) {
    2705         //Construct underlying thread to automatically
    2706         //be scheduled on the thread cluster
     2800        // Construct underlying thread to automatically
     2801        // be scheduled on the thread cluster
    27072802        (this){ thread_cluster }
    27082803}
     
    27102805void main(UThread & this);
    27112806
    2712 //Declares fibers
     2807// Declares fibers
    27132808thread Fiber {};
    27142809void ?{}(Fiber& this) {
    2715         //Construct underlying thread to automatically
    2716         //be scheduled on the fiber cluster
     2810        // Construct underlying thread to automatically
     2811        // be scheduled on the fiber cluster
    27172812        (this.__thread){ fibers_cluster }
    27182813}
    27192814
    27202815void main(Fiber & this);
    2721 \end{cfacode}
     2816\end{cfa}
    27222817\end{figure}
    27232818
     
    27632858
    27642859\section{Micro Benchmarks}
    2765 All benchmarks are run using the same harness to produce the results, seen as the \code{BENCH()} macro in the following examples.
     2860All benchmarks are run using the same harness to produce the results, seen as the @BENCH()@ macro in the following examples.
    27662861This macro uses the following logic to benchmark the code:
    2767 \begin{pseudo}
     2862\begin{cfa}
    27682863#define BENCH(run, result) \
    27692864        before = gettime(); \
     
    27712866        after  = gettime(); \
    27722867        result = (after - before) / N;
    2773 \end{pseudo}
    2774 The method used to get time is \code{clock_gettime(CLOCK_THREAD_CPUTIME_ID);}.
     2868\end{cfa}
     2869The method used to get time is @clock_gettime(CLOCK_THREAD_CPUTIME_ID);@.
    27752870Each benchmark is using many iterations of a simple call to measure the cost of the call.
    27762871The specific number of iterations depends on the specific benchmark.
     
    27872882\begin{multicols}{2}
    27882883\CFA Coroutines
    2789 \begin{cfacode}
     2884\begin{cfa}
    27902885coroutine GreatSuspender {};
    27912886void main(GreatSuspender& this) {
     
    28032898        printf("%llu\n", result);
    28042899}
    2805 \end{cfacode}
     2900\end{cfa}
    28062901\columnbreak
    28072902\CFA Threads
    2808 \begin{cfacode}
     2903\begin{cfa}
    28092904
    28102905
     
    28222917        printf("%llu\n", result);
    28232918}
    2824 \end{cfacode}
     2919\end{cfa}
    28252920\end{multicols}
    2826 \begin{cfacode}[caption={\CFA benchmark code used to measure context-switches for coroutines and threads.},label={lst:ctx-switch}]
    2827 \end{cfacode}
     2921\begin{cfa}[caption={\CFA benchmark code used to measure context-switches for coroutines and threads.},label={lst:ctx-switch}]
     2922\end{cfa}
    28282923\end{figure}
    28292924
     
    28532948For monitors, the simplest approach is to measure how long it takes to enter and leave a monitor routine.
    28542949Listing \ref{lst:mutex} shows the code for \CFA.
    2855 To put the results in context, the cost of entering a non-inline function and the cost of acquiring and releasing a \code{pthread_mutex} lock is also measured.
     2950To put the results in context, the cost of entering a non-inline function and the cost of acquiring and releasing a @pthread_mutex@ lock is also measured.
    28562951The results can be shown in table \ref{tab:mutex}.
    28572952
    28582953\begin{figure}
    2859 \begin{cfacode}[caption={\CFA benchmark code used to measure mutex routines.},label={lst:mutex}]
     2954\begin{cfa}[caption={\CFA benchmark code used to measure mutex routines.},label={lst:mutex}]
    28602955monitor M {};
    28612956void __attribute__((noinline)) call( M & mutex m /*, m2, m3, m4*/ ) {}
     
    28712966        printf("%llu\n", result);
    28722967}
    2873 \end{cfacode}
     2968\end{cfa}
    28742969\end{figure}
    28752970
     
    28832978FetchAdd + FetchSub                             & 26            & 26            & 0    \\
    28842979Pthreads Mutex Lock                             & 31            & 31.86 & 0.99 \\
    2885 \uC \code{monitor} member routine               & 30            & 30            & 0    \\
    2886 \CFA \code{mutex} routine, 1 argument   & 41            & 41.57 & 0.9  \\
    2887 \CFA \code{mutex} routine, 2 argument   & 76            & 76.96 & 1.57 \\
    2888 \CFA \code{mutex} routine, 4 argument   & 145           & 146.68        & 3.85 \\
     2980\uC @monitor@ member routine            & 30            & 30            & 0    \\
     2981\CFA @mutex@ routine, 1 argument        & 41            & 41.57 & 0.9  \\
     2982\CFA @mutex@ routine, 2 argument        & 76            & 76.96 & 1.57 \\
     2983\CFA @mutex@ routine, 4 argument        & 145           & 146.68        & 3.85 \\
    28892984Java synchronized routine                       & 27            & 28.57 & 2.6  \\
    28902985\hline
     
    29022997
    29032998\begin{figure}
    2904 \begin{cfacode}[caption={Benchmark code for internal scheduling},label={lst:int-sched}]
     2999\begin{cfa}[caption={Benchmark code for internal scheduling},label={lst:int-sched}]
    29053000volatile int go = 0;
    29063001condition c;
     
    29323027        return do_wait(m1);
    29333028}
    2934 \end{cfacode}
     3029\end{cfa}
    29353030\end{figure}
    29363031
     
    29423037\hline
    29433038Pthreads Condition Variable                     & 5902.5        & 6093.29       & 714.78 \\
    2944 \uC \code{signal}                                       & 322           & 323   & 3.36   \\
    2945 \CFA \code{signal}, 1 \code{monitor}    & 352.5 & 353.11        & 3.66   \\
    2946 \CFA \code{signal}, 2 \code{monitor}    & 430           & 430.29        & 8.97   \\
    2947 \CFA \code{signal}, 4 \code{monitor}    & 594.5 & 606.57        & 18.33  \\
    2948 Java \code{notify}                              & 13831.5       & 15698.21      & 4782.3 \\
     3039\uC @signal@                                    & 322           & 323   & 3.36   \\
     3040\CFA @signal@, 1 @monitor@      & 352.5 & 353.11        & 3.66   \\
     3041\CFA @signal@, 2 @monitor@      & 430           & 430.29        & 8.97   \\
     3042\CFA @signal@, 4 @monitor@      & 594.5 & 606.57        & 18.33  \\
     3043Java @notify@                           & 13831.5       & 15698.21      & 4782.3 \\
    29493044\hline
    29503045\end{tabular}
     
    29563051
    29573052\subsection{External Scheduling}
    2958 The Internal scheduling benchmark measures the cost of the \code{waitfor} statement (\code{_Accept} in \uC).
     3053The Internal scheduling benchmark measures the cost of the @waitfor@ statement (@_Accept@ in \uC).
    29593054Listing \ref{lst:ext-sched} shows the code for \CFA, with results in table \ref{tab:ext-sched}.
    29603055As with all other benchmarks, all omitted tests are functionally identical to one of these tests.
    29613056
    29623057\begin{figure}
    2963 \begin{cfacode}[caption={Benchmark code for external scheduling},label={lst:ext-sched}]
     3058\begin{cfa}[caption={Benchmark code for external scheduling},label={lst:ext-sched}]
    29643059volatile int go = 0;
    29653060monitor M {};
     
    29903085        return do_wait(m1);
    29913086}
    2992 \end{cfacode}
     3087\end{cfa}
    29933088\end{figure}
    29943089
     
    29993094\multicolumn{1}{c |}{} & \multicolumn{1}{c |}{ Median } &\multicolumn{1}{c |}{ Average } & \multicolumn{1}{c |}{ Standard Deviation} \\
    30003095\hline
    3001 \uC \code{Accept}                                       & 350           & 350.61        & 3.11  \\
    3002 \CFA \code{waitfor}, 1 \code{monitor}   & 358.5 & 358.36        & 3.82  \\
    3003 \CFA \code{waitfor}, 2 \code{monitor}   & 422           & 426.79        & 7.95  \\
    3004 \CFA \code{waitfor}, 4 \code{monitor}   & 579.5 & 585.46        & 11.25 \\
     3096\uC @Accept@                                    & 350           & 350.61        & 3.11  \\
     3097\CFA @waitfor@, 1 @monitor@     & 358.5 & 358.36        & 3.82  \\
     3098\CFA @waitfor@, 2 @monitor@     & 422           & 426.79        & 7.95  \\
     3099\CFA @waitfor@, 4 @monitor@     & 579.5 & 585.46        & 11.25 \\
    30053100\hline
    30063101\end{tabular}
     
    30203115\begin{center}
    30213116\texttt{pthread}
    3022 \begin{ccode}
     3117\begin{cfa}
    30233118int main() {
    30243119        BENCH(
     
    30393134        printf("%llu\n", result);
    30403135}
    3041 \end{ccode}
     3136\end{cfa}
    30423137
    30433138
    30443139
    30453140\CFA Threads
    3046 \begin{cfacode}
     3141\begin{cfa}
    30473142int main() {
    30483143        BENCH(
     
    30543149        printf("%llu\n", result);
    30553150}
    3056 \end{cfacode}
     3151\end{cfa}
    30573152\end{center}
    3058 \begin{cfacode}[caption={Benchmark code for \texttt{pthread}s and \CFA to measure object creation},label={lst:creation}]
    3059 \end{cfacode}
     3153\begin{cfa}[caption={Benchmark code for \texttt{pthread}s and \CFA to measure object creation},label={lst:creation}]
     3154\end{cfa}
    30603155\end{figure}
    30613156
     
    31413236\begin{tabular}[t]{|c|c|c|}
    31423237Sequential & Library Parallel & Language Parallel \\
    3143 \begin{cfacode}[tabsize=3]
     3238\begin{cfa}[tabsize=3]
    31443239void big_sum(
    31453240        int* a, int* b,
     
    31653260//... fill in a & b
    31663261big_sum(a,b,c,10000);
    3167 \end{cfacode} &\begin{cfacode}[tabsize=3]
     3262\end{cfa} &\begin{cfa}[tabsize=3]
    31683263void big_sum(
    31693264        int* a, int* b,
     
    31893284//... fill in a & b
    31903285big_sum(a,b,c,10000);
    3191 \end{cfacode}&\begin{cfacode}[tabsize=3]
     3286\end{cfa}&\begin{cfa}[tabsize=3]
    31923287void big_sum(
    31933288        int* a, int* b,
     
    32133308//... fill in a & b
    32143309big_sum(a,b,c,10000);
    3215 \end{cfacode}
     3310\end{cfa}
    32163311\end{tabular}
    32173312\end{center}
  • doc/papers/concurrency/annex/local.bib

    r6ecc079 raac7197  
    2121@string{pldi="Programming Language Design and Implementation"}
    2222
    23 
    24 @article{HPP:Study,
    25         keywords        = {Parallel, Productivity},
    26         author  = {Lorin Hochstein and Jeff Carver and Forrest Shull and Sima Asgari and Victor Basili and Jeffrey K. Hollingsworth and Marvin V. Zelkowitz },
    27         title   = {Parallel Programmer Productivity: A Case Study of Novice Parallel Programmers},
     23@inproceedings{Hochstein05,
     24    keywords    = {Application software; Computer aided software engineering; Concurrent computing; Educational
     25                  institutions; High performance computing; Humans; Instruments; Productivity; Programming profession;
     26                  Software engineering},
     27    author      = {Lorin Hochstein and Jeff Carver and Forrest Shull and Sima Asgari and Victor Basili and Jeffrey K. Hollingsworth and Marvin V. Zelkowitz},
     28    title       = {Parallel Programmer Productivity: A Case Study of Novice Parallel Programmers},
     29    booktitle   = {Supercomputing, 2005. Proceedings of the ACM/IEEE SC 2005 Conference},
     30    publisher   = {IEEE},
     31    year        = {2005},
     32    pages       = {35-35},
     33    month       = nov,
    2834}
    2935
     
    3541}
    3642
    37 @article{TBB,
    38         key     = {TBB},
    39         keywords        = {Intel, TBB},
    40         title   = {Intel Thread Building Blocks},
    41         note            = "\url{https://www.threadingbuildingblocks.org/}"
     43@misc{TBB,
     44    keywords    = {Intel, TBB},
     45    key         = {TBB},
     46    title       = {Thread Building Blocks},
     47    howpublished= {Intel, \url{https://www.threadingbuildingblocks.org}},
     48    note        = {Accessed: 2018-3},
    4249}
    4350
     
    4855        title   = {C$\forall$ Programmming Language},
    4956        note    = {\url{https://plg.uwaterloo.ca/~cforall}},
    50 }
    51 
    52 @mastersthesis{rob-thesis,
    53         keywords        = {Constructors, Destructors, Tuples},
    54         author  = {Rob Schluntz},
    55         title   = {Resource Management and Tuples in Cforall},
    56         year            = 2017,
    57         school  = {University of Waterloo},
    58         note    = {\url{https://uwspace.uwaterloo.ca/handle/10012/11830}},
    5957}
    6058
  • doc/papers/concurrency/style/cfa-format.tex

    r6ecc079 raac7197  
    1111% from https://gist.github.com/nikolajquorning/92bbbeef32e1dd80105c9bf2daceb89a
    1212\lstdefinelanguage{sml} {
    13   morekeywords= {
    14     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
    15   },
    16   morestring=[b]",
    17   morecomment=[s]{(*}{*)},
     13        morekeywords= {
     14                EQUAL, GREATER, LESS, NONE, SOME, abstraction, abstype, and, andalso, array, as, before,
     15                bool, case, char, datatype, do, else, end, eqtype, exception, exn, false, fn, fun, functor,
     16                handle, if, in, include, infix, infixr, int, let, list, local, nil, nonfix, not, o, of, op,
     17                open, option, orelse, overload, print, raise, real, rec, ref, sharing, sig, signature,
     18                string, struct, structure, substring, then, true, type, unit, val, vector, where, while,
     19                with, withtype, word
     20    },
     21    morestring=[b]",
     22    morecomment=[s]{(*}{*)},
    1823}
    1924
    2025\lstdefinelanguage{D}{
    21   % Keywords
    22   morekeywords=[1]{
    23     abstract, alias, align, auto, body, break, cast, catch, class, const,
    24     continue, debug, delegate, delete, deprecated, do, else, enum, export,
    25     false, final, finally, for, foreach, foreach_reverse, function, goto, if,
    26     immutable, import, in, inout, interface, invariant, is, lazy, macro, mixin,
    27     module, new, nothrow, null, out, override, package, pragma, private,
    28     protected, public, pure, ref, return, shared, static, struct, super,
    29     switch, synchronized, template, this, throw, true, try, typedef, typeid,
    30     typeof, union, unittest, volatile, while, with
    31   },
    32   % Special identifiers, common functions
    33   morekeywords=[2]{enforce},
    34   % Ugly identifiers
    35   morekeywords=[3]{
    36     __DATE__, __EOF__, __FILE__, __LINE__, __TIMESTAMP__, __TIME__, __VENDOR__,
    37     __VERSION__, __ctfe, __gshared, __monitor, __thread, __vptr, _argptr,
    38     _arguments, _ctor, _dtor
    39   },
    40   % Basic types
    41   morekeywords=[4]{
    42      byte, ubyte, short, ushort, int, uint, long, ulong, cent, ucent, void,
    43      bool, bit, float, double, real, ushort, int, uint, long, ulong, float,
    44      char, wchar, dchar, string, wstring, dstring, ireal, ifloat, idouble,
    45      creal, cfloat, cdouble, size_t, ptrdiff_t, sizediff_t, equals_t, hash_t
    46   },
    47   % Strings
    48   morestring=[b]{"},
    49   morestring=[b]{'},
    50   morestring=[b]{`},
    51   % Comments
    52   comment=[l]{//},
    53   morecomment=[s]{/*}{*/},
    54   morecomment=[s][\color{blue}]{/**}{*/},
    55   morecomment=[n]{/+}{+/},
    56   morecomment=[n][\color{blue}]{/++}{+/},
    57   % Options
    58   sensitive=true
     26        % Keywords
     27        morekeywords=[1]{
     28                abstract, alias, align, auto, body, break, cast, catch, class, const, continue, debug,
     29                delegate, delete, deprecated, do, else, enum, export, false, final, finally, for, foreach,
     30                foreach_reverse, function, goto, if, immutable, import, in, inout, interface, invariant, is,
     31                lazy, macro, mixin, module, new, nothrow, null, out, override, package, pragma, private,
     32                protected, public, pure, ref, return, shared, static, struct, super, switch, synchronized,
     33                template, this, throw, true, try, typedef, typeid, typeof, union, unittest, volatile, while,
     34                with
     35        },
     36        % Special identifiers, common functions
     37        morekeywords=[2]{enforce},
     38        % Ugly identifiers
     39        morekeywords=[3]{
     40                __DATE__, __EOF__, __FILE__, __LINE__, __TIMESTAMP__, __TIME__, __VENDOR__,
     41                __VERSION__, __ctfe, __gshared, __monitor, __thread, __vptr, _argptr,
     42                _arguments, _ctor, _dtor
     43        },
     44        % Basic types
     45        morekeywords=[4]{
     46                byte, ubyte, short, ushort, int, uint, long, ulong, cent, ucent, void, bool, bit, float,
     47                double, real, ushort, int, uint, long, ulong, float, char, wchar, dchar, string, wstring,
     48                dstring, ireal, ifloat, idouble, creal, cfloat, cdouble, size_t, ptrdiff_t, sizediff_t,
     49                equals_t, hash_t
     50        },
     51        % Strings
     52        morestring=[b]{"},
     53        morestring=[b]{'},
     54        morestring=[b]{`},
     55        % Comments
     56        comment=[l]{//},
     57        morecomment=[s]{/*}{*/},
     58        morecomment=[s][\color{blue}]{/**}{*/},
     59        morecomment=[n]{/+}{+/},
     60        morecomment=[n][\color{blue}]{/++}{+/},
     61        % Options
     62        sensitive=true
    5963}
    6064
    6165\lstdefinelanguage{rust}{
    62   % Keywords
    63   morekeywords=[1]{
    64     abstract, alignof, as, become, box,
    65     break, const, continue, crate, do,
    66     else, enum, extern, false, final,
    67     fn, for, if, impl, in,
    68     let, loop, macro, match, mod,
    69     move, mut, offsetof, override, priv,
    70     proc, pub, pure, ref, return,
    71     Self, self, sizeof, static, struct,
    72     super, trait, true,  type, typeof,
    73     unsafe, unsized, use, virtual, where,
    74     while, yield
    75   },
    76   % Strings
    77   morestring=[b]{"},
    78   % Comments
    79   comment=[l]{//},
    80   morecomment=[s]{/*}{*/},
    81   % Options
    82   sensitive=true
     66        % Keywords
     67        morekeywords=[1]{
     68                abstract, alignof, as, become, box, break, const, continue, crate, do, else, enum, extern,
     69                false, final, fn, for, if, impl, in, let, loop, macro, match, mod, move, mut, offsetof,
     70                override, priv, proc, pub, pure, ref, return, Self, self, sizeof, static, struct, super,
     71                trait, true, type, typeof, unsafe, unsized, use, virtual, where, while, yield
     72        },
     73        % Strings
     74        morestring=[b]{"},
     75        % Comments
     76        comment=[l]{//},
     77        morecomment=[s]{/*}{*/},
     78        % Options
     79        sensitive=true
    8380}
    8481
    8582\lstdefinelanguage{pseudo}{
    86         morekeywords={string,uint,int,bool,float},%
    87         sensitive=true,%
    88         morecomment=[l]{//},%
    89         morecomment=[s]{/*}{*/},%
    90         morestring=[b]',%
    91         morestring=[b]",%
    92         morestring=[s]{`}{`},%
    93 }%
     83        morekeywords={string,uint,int,bool,float},
     84        sensitive=true,
     85        morecomment=[l]{//},
     86        morecomment=[s]{/*}{*/},
     87        morestring=[b]',
     88        morestring=[b]",
     89        morestring=[s]{`}{`},
     90}
    9491
    9592\newcommand{\KWC}{K-W C\xspace}
    9693
    9794\lstdefinestyle{pseudoStyle}{
    98   escapeinside={@@},
    99   basicstyle=\linespread{0.9}\sf\footnotesize,          % reduce line spacing and use typewriter font
    100   keywordstyle=\bfseries\color{blue},
    101   keywordstyle=[2]\bfseries\color{Plum},
    102   commentstyle=\itshape\color{OliveGreen},                  % green and italic comments
    103   identifierstyle=\color{identifierCol},
    104   stringstyle=\sf\color{Mahogany},                                % use sanserif font
    105   mathescape=true,
    106   columns=fixed,
    107   aboveskip=4pt,                                  % spacing above/below code block
    108   belowskip=3pt,
    109   keepspaces=true,
    110   tabsize=4,
    111   % frame=lines,
    112   literate=,
    113   showlines=true,                                % show blank lines at end of code
    114   showspaces=false,
    115   showstringspaces=false,
    116   escapechar=\$,
    117   xleftmargin=\parindentlnth,                     % indent code to paragraph indentation
    118   moredelim=[is][\color{red}\bfseries]{**R**}{**R**},    % red highlighting
    119   % moredelim=* detects keywords, comments, strings, and other delimiters and applies their formatting
    120   % moredelim=** allows cumulative application
     95        escapeinside={@@},
     96        basicstyle=\linespread{0.9}\sf\footnotesize,            % reduce line spacing and use typewriter font
     97        keywordstyle=\bfseries\color{blue},
     98        keywordstyle=[2]\bfseries\color{Plum},
     99        commentstyle=\itshape\color{OliveGreen},                    % green and italic comments
     100        identifierstyle=\color{identifierCol},
     101        stringstyle=\sf\color{Mahogany},                                          % use sanserif font
     102        mathescape=true,
     103        columns=fixed,
     104        aboveskip=4pt,                                                            % spacing above/below code block
     105        belowskip=3pt,
     106        keepspaces=true,
     107        tabsize=4,
     108        % frame=lines,
     109        literate=,
     110        showlines=true,                                                          % show blank lines at end of code
     111        showspaces=false,
     112        showstringspaces=false,
     113        escapechar=\$,
     114        xleftmargin=\parindentlnth,                                  % indent code to paragraph indentation
     115        moredelim=[is][\color{red}\bfseries]{**R**}{**R**},    % red highlighting
     116        % moredelim=* detects keywords, comments, strings, and other delimiters and applies their formatting
     117        % moredelim=** allows cumulative application
    121118}
    122119
    123120\lstdefinestyle{defaultStyle}{
    124   escapeinside={@@},
    125   basicstyle=\linespread{0.9}\tt\footnotesize,          % reduce line spacing and use typewriter font
    126   keywordstyle=\bfseries\color{blue},
    127   keywordstyle=[2]\bfseries\color{Plum},
    128   commentstyle=\itshape\color{OliveGreen},                  % green and italic comments
    129   identifierstyle=\color{identifierCol},
    130   stringstyle=\sf\color{Mahogany},                                % use sanserif font
    131   mathescape=true,
    132   columns=fixed,
    133   aboveskip=4pt,                                  % spacing above/below code block
    134   belowskip=3pt,
    135   keepspaces=true,
    136   tabsize=4,
    137   % frame=lines,
    138   literate=,
    139   showlines=true,                                % show blank lines at end of code
    140   showspaces=false,
    141   showstringspaces=false,
    142   escapechar=\$,
    143   xleftmargin=\parindentlnth,                     % indent code to paragraph indentation
    144   moredelim=[is][\color{red}\bfseries]{**R**}{**R**},    % red highlighting
    145   % moredelim=* detects keywords, comments, strings, and other delimiters and applies their formatting
    146   % moredelim=** allows cumulative application
     121        escapeinside={@@},
     122        basicstyle=\linespread{0.9}\tt\footnotesize,            % reduce line spacing and use typewriter font
     123        keywordstyle=\bfseries\color{blue},
     124        keywordstyle=[2]\bfseries\color{Plum},
     125        commentstyle=\itshape\color{OliveGreen},                    % green and italic comments
     126        identifierstyle=\color{identifierCol},
     127        stringstyle=\sf\color{Mahogany},                                          % use sanserif font
     128        mathescape=true,
     129        columns=fixed,
     130        aboveskip=4pt,                                                            % spacing above/below code block
     131        belowskip=3pt,
     132        keepspaces=true,
     133        tabsize=4,
     134        % frame=lines,
     135        literate=,
     136        showlines=true,                                                          % show blank lines at end of code
     137        showspaces=false,
     138        showstringspaces=false,
     139        escapechar=\$,
     140        xleftmargin=\parindentlnth,                                  % indent code to paragraph indentation
     141        moredelim=[is][\color{red}\bfseries]{**R**}{**R**},    % red highlighting
     142        % moredelim=* detects keywords, comments, strings, and other delimiters and applies their formatting
     143        % moredelim=** allows cumulative application
    147144}
    148145
    149146\lstdefinestyle{cfaStyle}{
    150   escapeinside={@@},
    151   basicstyle=\linespread{0.9}\sf,               % reduce line spacing and use typewriter font
     147        escapeinside={@@},
     148        basicstyle=\linespread{0.9}\sf,         % reduce line spacing and use typewriter font
    152149%  keywordstyle=\bfseries\color{blue},
    153   keywordstyle=[2]\bfseries\color{red},
     150        keywordstyle=[2]\bfseries\color{red},
    154151%  commentstyle=\sf\itshape\color{OliveGreen},            % green and italic comments
    155   identifierstyle=\color{identifierCol},
    156 %  stringstyle=\sf\color{Mahogany},                               % use sanserif font
    157   stringstyle=\tt,                                                                              % use typewriter font
    158   mathescape=true,
    159   columns=fixed,
    160   aboveskip=4pt,                                  % spacing above/below code block
    161   belowskip=3pt,
    162   keepspaces=true,
    163   tabsize=4,
    164   % frame=lines,
    165   literate=,
    166   showlines=true,                                % show blank lines at end of code
    167   showspaces=false,
    168   showstringspaces=false,
    169   escapechar=\$,
    170   xleftmargin=\parindentlnth,                     % indent code to paragraph indentation
    171   moredelim=[is][\color{red}\bfseries]{**R**}{**R**},    % red highlighting
    172   morekeywords=[2]{accept, signal, signal_block, wait, waitfor},
     152        identifierstyle=\color{identifierCol},
     153%  stringstyle=\sf\color{Mahogany},                                       % use sanserif font
     154        stringstyle=\tt,                                                                                % use typewriter font
     155        mathescape=true,
     156        columns=fixed,
     157        aboveskip=4pt,                                                            % spacing above/below code block
     158        belowskip=3pt,
     159        keepspaces=true,
     160        tabsize=4,
     161        % frame=lines,
     162        literate=,
     163        showlines=true,                                                          % show blank lines at end of code
     164        showspaces=false,
     165        showstringspaces=false,
     166        escapechar=\$,
     167        xleftmargin=\parindentlnth,                                  % indent code to paragraph indentation
     168        moredelim=[is][\color{red}\bfseries]{**R**}{**R**},    % red highlighting
     169        morekeywords=[2]{accept, signal, signal_block, wait, waitfor},
    173170}
    174171
     
    176173
    177174\lstnewenvironment{ccode}[1][]{
    178   \lstset{
    179     language = C,
    180     style=defaultStyle,
    181     captionpos=b,
    182     #1
    183   }
     175        \lstset{
     176                language = C,
     177                style=defaultStyle,
     178                captionpos=b,
     179                #1
     180        }
    184181}{}
    185182
    186183\lstnewenvironment{cfacode}[1][]{
    187   \lstset{
    188     language = CFA,
    189     style=cfaStyle,
    190     captionpos=b,
    191     #1
    192   }
     184        \lstset{
     185                language = CFA,
     186                style=cfaStyle,
     187                captionpos=b,
     188                #1
     189        }
    193190}{}
    194191
    195192\lstnewenvironment{pseudo}[1][]{
    196   \lstset{
    197     language = pseudo,
    198     style=pseudoStyle,
    199     captionpos=b,
    200     #1
    201   }
     193        \lstset{
     194                language = pseudo,
     195                style=pseudoStyle,
     196                captionpos=b,
     197                #1
     198        }
    202199}{}
    203200
    204201\lstnewenvironment{cppcode}[1][]{
    205   \lstset{
    206     language = c++,
    207     style=defaultStyle,
    208     captionpos=b,
    209     #1
    210   }
     202        \lstset{
     203                language = c++,
     204                style=defaultStyle,
     205                captionpos=b,
     206                #1
     207        }
    211208}{}
    212209
    213210\lstnewenvironment{ucppcode}[1][]{
    214   \lstset{
    215     language = c++,
    216     style=defaultStyle,
    217     captionpos=b,
    218     #1
    219   }
     211        \lstset{
     212                language = c++,
     213                style=defaultStyle,
     214                captionpos=b,
     215                #1
     216        }
    220217}{}
    221218
    222219\lstnewenvironment{javacode}[1][]{
    223   \lstset{
    224     language = java,
    225     style=defaultStyle,
    226     captionpos=b,
    227     #1
    228   }
     220        \lstset{
     221                language = java,
     222                style=defaultStyle,
     223                captionpos=b,
     224                #1
     225        }
    229226}{}
    230227
    231228\lstnewenvironment{scalacode}[1][]{
    232   \lstset{
    233     language = scala,
    234     style=defaultStyle,
    235     captionpos=b,
    236     #1
    237   }
     229        \lstset{
     230                language = scala,
     231                style=defaultStyle,
     232                captionpos=b,
     233                #1
     234        }
    238235}{}
    239236
    240237\lstnewenvironment{smlcode}[1][]{
    241   \lstset{
    242     language = sml,
    243     style=defaultStyle,
    244     captionpos=b,
    245     #1
    246   }
     238        \lstset{
     239                language = sml,
     240                style=defaultStyle,
     241                captionpos=b,
     242                #1
     243        }
    247244}{}
    248245
    249246\lstnewenvironment{dcode}[1][]{
    250   \lstset{
    251     language = D,
    252     style=defaultStyle,
    253     captionpos=b,
    254     #1
    255   }
     247        \lstset{
     248                language = D,
     249                style=defaultStyle,
     250                captionpos=b,
     251                #1
     252        }
    256253}{}
    257254
    258255\lstnewenvironment{rustcode}[1][]{
    259   \lstset{
    260     language = rust,
    261     style=defaultStyle,
    262     captionpos=b,
    263     #1
    264   }
     256        \lstset{
     257                language = rust,
     258                style=defaultStyle,
     259                captionpos=b,
     260                #1
     261        }
    265262}{}
    266263
    267264\lstnewenvironment{gocode}[1][]{
    268   \lstset{
    269     language = Golang,
    270     style=defaultStyle,
    271     captionpos=b,
    272     #1
    273   }
     265        \lstset{
     266                language = Golang,
     267                style=defaultStyle,
     268                captionpos=b,
     269                #1
     270        }
    274271}{}
    275272
     
    279276\newcommand{\code}[1]{\lstinline[language=CFA,style=cfaStyle]{#1}}
    280277\newcommand{\pscode}[1]{\lstinline[language=pseudo,style=pseudoStyle]{#1}}
     278
     279% Local Variables: %
     280% tab-width: 4 %
     281% fill-column: 100 %
     282% End: %
Note: See TracChangeset for help on using the changeset viewer.