source: doc/proposals/concurrency/concurrency.tex @ f7ff3fb

aaron-thesisarm-ehcleanup-dtorsdeferred_resndemanglerjacob/cs343-translationjenkins-sandboxnew-astnew-ast-unique-exprnew-envno_listpersistent-indexerresolv-newwith_gc
Last change on this file since f7ff3fb was f7ff3fb, checked in by Thierry Delisle <tdelisle@…>, 5 years ago

Some more work on concurrency proposal paper

  • Property mode set to 100644
File size: 57.8 KB
Line 
1% requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
2
3% inline code ©...© (copyright symbol) emacs: C-q M-)
4% red highlighting ®...® (registered trademark symbol) emacs: C-q M-.
5% blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_
6% green highlighting ¢...¢ (cent symbol) emacs: C-q M-"
7% LaTex escape §...§ (section symbol) emacs: C-q M-'
8% keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
9% math escape $...$ (dollar symbol)
10
11\documentclass[twoside,11pt]{article}
12
13%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
14
15% Latex packages used in the document.
16\usepackage[T1]{fontenc}                                        % allow Latin1 (extended ASCII) characters
17\usepackage{textcomp}
18\usepackage[latin1]{inputenc}
19\usepackage{fullpage,times,comment}
20\usepackage{epic,eepic}
21\usepackage{upquote}                                            % switch curled `'" to straight
22\usepackage{calc}
23\usepackage{xspace}
24\usepackage{graphicx}
25\usepackage{tabularx}
26\usepackage[acronym]{glossaries}
27\usepackage{varioref}                                           % extended references
28\usepackage{inconsolata}
29\usepackage{listings}                                           % format program code
30\usepackage[flushmargin]{footmisc}                              % support label/reference in footnote
31\usepackage{latexsym}                                           % \Box glyph
32\usepackage{mathptmx}                                           % better math font with "times"
33\usepackage[usenames]{color}
34\usepackage[pagewise]{lineno}
35\usepackage{fancyhdr}
36\renewcommand{\linenumberfont}{\scriptsize\sffamily}
37\input{style}                                                   % bespoke macros used in the document
38\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
39\usepackage{breakurl}
40
41\usepackage{tikz}
42\def\checkmark{\tikz\fill[scale=0.4](0,.35) -- (.25,0) -- (1,.7) -- (.25,.15) -- cycle;}
43
44\renewcommand{\UrlFont}{\small\sf}
45
46\setlength{\topmargin}{-0.45in}                         % move running title into header
47\setlength{\headsep}{0.25in}
48
49%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
50
51% Names used in the document.
52
53\newcommand{\Version}{1.0.0}
54\newcommand{\CS}{C\raisebox{-0.9ex}{\large$^\sharp$}\xspace}
55
56\newcommand{\Textbf}[2][red]{{\color{#1}{\textbf{#2}}}}
57\newcommand{\Emph}[2][red]{{\color{#1}\textbf{\emph{#2}}}}
58\newcommand{\R}[1]{\Textbf{#1}}
59\newcommand{\B}[1]{{\Textbf[blue]{#1}}}
60\newcommand{\G}[1]{{\Textbf[OliveGreen]{#1}}}
61\newcommand{\uC}{$\mu$\CC}
62\newcommand{\cit}{\textsuperscript{[Citation Needed]}\xspace}
63\newcommand{\code}[1]{\lstinline{#1}}
64\newcommand{\pseudo}[1]{\lstinline[language=Pseudo]{#1}}
65
66\input{glossary}
67
68\newsavebox{\LstBox}
69
70%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
71
72\setcounter{secnumdepth}{3}                             % number subsubsections
73\setcounter{tocdepth}{3}                                % subsubsections in table of contents
74% \linenumbers                                            % comment out to turn off line numbering
75\makeindex
76\pagestyle{fancy}
77\fancyhf{}
78\cfoot{\thepage}
79\rfoot{v\input{version}}
80
81%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
82
83\begin{document}
84% \linenumbers
85
86\title{Concurrency in \CFA}
87\author{Thierry Delisle \\
88School of Computer Science, University of Waterloo, \\ Waterloo, Ontario, Canada
89}
90
91\maketitle
92
93% ### #     # ####### ######  #######
94%  #  ##    #    #    #     # #     #
95%  #  # #   #    #    #     # #     #
96%  #  #  #  #    #    ######  #     #
97%  #  #   # #    #    #   #   #     #
98%  #  #    ##    #    #    #  #     #
99% ### #     #    #    #     # #######
100
101\section{Introduction}
102This proposal provides a minimal core concurrency API that is both simple, efficient and can be reused to build higher-level features. The simplest possible concurrency core is a thread and a lock but this low-level approach is hard to master. An easier approach for users is to support higher-level constructs as the basis of the concurrency in \CFA. Indeed, for highly productive parallel programming, high-level approaches are much more popular~\cite{HPP:Study}. Examples are task based, message passing and implicit threading.
103
104There are actually two problems that need to be solved in the design of the concurrency for a programming language: which concurrency tools are available to the users and which parallelism tools are available. While these two concepts are often seen together, they are in fact distinct concepts that require different sorts of tools~\cite{Buhr05a}. Concurrency tools need to handle mutual exclusion and synchronization, while parallelism tools are more about performance, cost and resource utilization.
105
106%  #####  ####### #     #  #####  #     # ######  ######  ####### #     #  #####  #     #
107% #     # #     # ##    # #     # #     # #     # #     # #       ##    # #     #  #   #
108% #       #     # # #   # #       #     # #     # #     # #       # #   # #         # #
109% #       #     # #  #  # #       #     # ######  ######  #####   #  #  # #          #
110% #       #     # #   # # #       #     # #   #   #   #   #       #   # # #          #
111% #     # #     # #    ## #     # #     # #    #  #    #  #       #    ## #     #    #
112%  #####  ####### #     #  #####   #####  #     # #     # ####### #     #  #####     #
113
114\section{Concurrency}
115Several tool can be used to solve concurrency challenges. Since these challenges always appear with the use of mutable shared-state, some languages and libraries simply disallow mutable shared-state (Erlang~\cite{Erlang}, Haskell~\cite{Haskell}, Akka (Scala)~\cite{Akka}). In these paradigms, interaction among concurrent objects relies on message passing~\cite{Thoth,Harmony,V-Kernel} or other paradigms that closely relate to networking concepts (channels\cit for example). However, in languages that use routine calls as their core abstraction mechanism, these approaches force a clear distinction between concurrent and non-concurrent paradigms (i.e., message passing versus routine call). Which in turn means that, in order to be effective, programmers need to learn two sets of designs patterns. This distinction can be hidden away in library code, but effective use of the librairy still has to take both paradigms into account. Approaches based on shared memory are more closely related to non-concurrent paradigms since they often rely on basic constructs like routine calls and objects. At a lower level these can be implemented as locks and atomic operations. Many such mechanisms have been proposed, including semaphores~\cite{Dijkstra68b} and path expressions~\cite{Campbell74}. However, for productivity reasons it is desireable to have a higher-level construct be the core concurrency paradigm~\cite{HPP:Study}. An approach that is worth mentionning because it is gaining in popularity is transactionnal memory~\cite{Dice10}[Check citation]. While this approach is even pursued by system languages like \CC\cit, the performance and feature set is currently too restrictive to add such a paradigm to a language like C or \CC\cit, which is why it was rejected as the core paradigm for concurrency in \CFA. One of the most natural, elegant, and efficient mechanisms for synchronization and communication, especially for shared memory systems, is the \emph{monitor}. Monitors were first proposed by Brinch Hansen~\cite{Hansen73} and later described and extended by C.A.R.~Hoare~\cite{Hoare74}. Many programming languages---e.g., Concurrent Pascal~\cite{ConcurrentPascal}, Mesa~\cite{Mesa}, Modula~\cite{Modula-2}, Turing~\cite{Turing:old}, Modula-3~\cite{Modula-3}, NeWS~\cite{NeWS}, Emerald~\cite{Emerald}, \uC~\cite{Buhr92a} and Java~\cite{Java}---provide monitors as explicit language constructs. In addition, operating-system kernels and device drivers have a monitor-like structure, although they often use lower-level primitives such as semaphores or locks to simulate monitors. For these reasons, this project proposes monitors as the core concurrency construct.
116
117% #     # ####### #     # ### ####### ####### ######   #####
118% ##   ## #     # ##    #  #     #    #     # #     # #     #
119% # # # # #     # # #   #  #     #    #     # #     # #
120% #  #  # #     # #  #  #  #     #    #     # ######   #####
121% #     # #     # #   # #  #     #    #     # #   #         #
122% #     # #     # #    ##  #     #    #     # #    #  #     #
123% #     # ####### #     # ###    #    ####### #     #  #####
124
125\subsection{Monitors}
126A monitor is a set of routines that ensure mutual exclusion when accessing shared state. This concept is generally associated with Object-Oriented Languages like Java~\cite{Java} or \uC~\cite{uC++book} but does not strictly require OOP semantics. The only requirements is the ability to declare a handle to a shared object and a set of routines that act on it :
127\begin{lstlisting}
128        typedef /*some monitor type*/ monitor;
129        int f(monitor & m);
130
131        int main() {
132                monitor m;
133                f(m);
134        }
135\end{lstlisting}
136
137%  #####     #    #       #
138% #     #   # #   #       #
139% #        #   #  #       #
140% #       #     # #       #
141% #       ####### #       #
142% #     # #     # #       #
143%  #####  #     # ####### #######
144
145\subsubsection{Call semantics} \label{call}
146The above monitor example displays some of the intrinsic characteristics. Indeed, it is necessary to use pass-by-reference over pass-by-value for monitor routines. This semantics is important because at their core, monitors are implicit mutual-exclusion objects (locks), and these objects cannot be copied. Therefore, monitors are implicitly non-copyable.
147
148Another aspect to consider is when a monitor acquires its mutual exclusion. For example, a monitor may need to be passed through multiple helper routines that do not acquire the monitor mutual-exclusion on entry. Pass through can be both generic helper routines (\code{swap}, \code{sort}, etc.) or specific helper routines like the following to implement an atomic counter :
149
150\begin{lstlisting}
151        mutex struct counter_t { /*...see section §\ref{data}§...*/ };
152
153        void ?{}(counter_t & nomutex this); //constructor
154        size_t ++?(counter_t & mutex this); //increment
155
156        //need for mutex is platform dependent here
157        void ?{}(size_t * this, counter_t & mutex cnt); //conversion
158\end{lstlisting}
159
160Here, the constructor(\code{?\{\}}) uses the \code{nomutex} keyword to signify that it does not acquire the monitor mutual exclusion when constructing. This semantics is because an object not yet constructed should never be shared and therefore does not require mutual exclusion. The prefix increment operator uses \code{mutex} to protect the incrementing process from race conditions. Finally, there is a conversion operator from \code{counter_t} to \code{size_t}. This conversion may or may not require the \code{mutex} key word depending on whether or not reading an \code{size_t} is an atomic operation or not.
161
162Having both \code{mutex} and \code{nomutex} keywords could be argued to be redundant based on the meaning of a routine having neither of these keywords. For example, given a routine without wualifiers \code{void foo(counter_t & this)} then one could argue that it should default to the safest option \code{mutex}. On the other hand, the option of having routine \code{void foo(counter_t & this)} mean \code{nomutex} is unsafe by default and may easily cause subtle errors. It can be argued that \code{nomutex} is the more "normal" behaviour, the \code{nomutex} keyword effectively stating explicitly that "this routine has nothing special". Another alternative is to make having exactly one of these keywords mandatory, which would provide the same semantics but without the ambiguity of supporting routine \code{void foo(counter_t & this)}. Mandatory keywords would also have the added benefice of being self-documented but at the cost of extra typing. In the end, which solution should be picked is still up for debate. For the reminder of this proposal, the explicit approach is used for clarity.
163
164The next semantic decision is to establish when mutex/nomutex may be used as a type qualifier. Consider the following declarations:
165\begin{lstlisting}
166        int f1(monitor & mutex m);
167        int f2(const monitor & mutex m);
168        int f3(monitor ** mutex m);
169        int f4(monitor *[] mutex m);
170        int f5(graph(monitor*) & mutex m);
171\end{lstlisting}
172The problem is to indentify which object(s) should be acquired. Furthermore, each object needs to be acquired only once. In the case of simple routines like \code{f1} and \code{f2} it is easy to identify an exhaustive list of objects to acquire on entry. Adding indirections (\code{f3}) still allows the compiler and programmer to indentify which object is acquired. However, adding in arrays (\code{f4}) makes it much harder. Array lengths are not necessarily known in C and even then making sure we only acquire objects once becomes also none trivial. This can be extended to absurd limits like \code{f5}, which uses a graph of monitors. To keep everyone as sane as possible~\cite{Chicken}, this projects imposes the requirement that a routine may only acquire one monitor per parameter and it must be the type of the parameter (ignoring potential qualifiers and indirections). Also note that while routine \code{f3} can be supported, meaning that monitor \code{**m} is be acquired, passing an array to this routine would be type safe and yet result in undefined behavior because only the first element of the array is acquired. However, this ambiguity is part of the C type system with respects to arrays. For this reason, it would also be reasonnable to disallow mutex in the context where arrays may be passed.
173
174% ######     #    #######    #
175% #     #   # #      #      # #
176% #     #  #   #     #     #   #
177% #     # #     #    #    #     #
178% #     # #######    #    #######
179% #     # #     #    #    #     #
180% ######  #     #    #    #     #
181
182\subsubsection{Data semantics} \label{data}
183Once the call semantics are established, the next step is to establish data semantics. Indeed, until now a monitor is used simply as a generic handle but in most cases monitors contian shared data. This data should be intrinsic to the monitor declaration to prevent any accidental use of data without its appropriate protection. For example, here is a complete version of the counter showed in section \ref{call}:
184\begin{lstlisting}
185        mutex struct counter_t {
186                int value;
187        };
188
189        void ?{}(counter_t & nomutex this) {
190                this.cnt = 0;
191        }
192
193        int ++?(counter_t & mutex this) {
194                return ++this.value;
195        }
196
197        //need for mutex is platform dependent here
198        void ?{}(int * this, counter_t & mutex cnt) {
199                *this = (int)cnt;
200        }
201\end{lstlisting}
202
203This simple counter is used as follows:
204\begin{center}
205\begin{tabular}{c @{\hskip 0.35in} c @{\hskip 0.35in} c}
206\begin{lstlisting}
207        //shared counter
208        counter_t cnt;
209
210        //multiple threads access counter
211        thread 1 : cnt++;
212        thread 2 : cnt++;
213        thread 3 : cnt++;
214          ...
215        thread N : cnt++;
216\end{lstlisting}
217\end{tabular}
218\end{center}
219
220Notice how the counter is used without any explicit synchronisation and yet supports thread-safe semantics for both reading and writting. Unlike object-oriented monitors, where calling a mutex member \emph{implicitly} acquires mutual-exclusion, \CFA uses an explicit mechanism to acquire mutual-exclusion. A consequence of this approach is that it extends to multi-monitor calls.
221\begin{lstlisting}
222        int f(MonitorA & mutex a, MonitorB & mutex b);
223
224        MonitorA a;
225        MonitorB b;
226        f(a,b);
227\end{lstlisting}
228This code acquires both locks before entering the critical section, called \emph{\gls{group-acquire}}. In practice, writing multi-locking routines that do not lead to deadlocks is tricky. Having language support for such a feature is therefore a significant asset for \CFA. In the case presented above, \CFA guarantees that the order of aquisition is consistent across calls to routines using the same monitors as arguments. However, since \CFA monitors use multi-acquisition locks, users can effectively force the acquiring order. For example, notice which routines use \code{mutex}/\code{nomutex} and how this affects aquiring order :
229\begin{lstlisting}
230        void foo(A & mutex a, B & mutex b) { //acquire a & b
231                //...
232        }
233
234        void bar(A & mutex a, B & nomutex b) { //acquire a
235                //...
236                foo(a, b); //acquire b
237                //...
238        }
239
240        void baz(A & nomutex a, B & mutex b) { //acquire b
241                //...
242                foo(a, b); //acquire a
243                //...
244        }
245\end{lstlisting}
246
247The multi-acquisition monitor lock allows a monitor lock to be acquired by both \code{bar} or \code{baz} and acquired again in \code{foo}. In the calls to \code{bar} and \code{baz} the monitors are acquired in opposite order. such use leads to nested monitor call problems~\cite{Lister77}, which is a specific implementation of the lock acquiring order problem. In the example above, the user uses implicit ordering in the case of function \code{foo} but explicit ordering in the case of \code{bar} and \code{baz}. This subtle mistake means that calling these routines concurrently may lead to deadlock and is therefore undefined behavior. As shown on several occasion\cit, solving this problem requires :
248\begin{enumerate}
249        \item Dynamically tracking of the monitor-call order.
250        \item Implement rollback semantics.
251\end{enumerate}
252
253While the first requirement is already a significant constraint on the system, implementing a general rollback semantics in a C-like language is prohibitively complex \cit. In \CFA, users simply need to be carefull when acquiring multiple monitors at the same time.
254
255% ######  ####### #######    #    ### #        #####
256% #     # #          #      # #    #  #       #     #
257% #     # #          #     #   #   #  #       #
258% #     # #####      #    #     #  #  #        #####
259% #     # #          #    #######  #  #             #
260% #     # #          #    #     #  #  #       #     #
261% ######  #######    #    #     # ### #######  #####
262%
263%             ######  ####### #       #     # #     # ####### ######  #     #
264%             #     # #     # #        #   #  ##   ## #     # #     # #     #
265%             #     # #     # #         # #   # # # # #     # #     # #     #
266%  #####    ######  #     # #          #    #  #  # #     # ######  #######
267%             #       #     # #          #    #     # #     # #   #   #     #
268%             #       #     # #          #    #     # #     # #    #  #     #
269%             #       ####### #######    #    #     # ####### #     # #     #
270
271\subsubsection{Implementation Details: Interaction with polymorphism}
272At first glance, interaction between monitors and \CFA's concept of polymorphism seems complex to support. However, it is shown that entry-point locking can solve most of the issues.
273
274Before looking into complex control flow, it is important to present the difference between the two acquiring options : \gls{callsite-locking} and \gls{entry-point-locking}, i.e. acquiring the monitors before making a mutex call or as the first instruction of the mutex call. For example:
275
276\begin{center}
277\begin{tabular}{|c|c|c|}
278Code & \gls{callsite-locking} & \gls{entry-point-locking} \\
279\CFA & pseudo-code & pseudo-code \\
280\hline
281\begin{lstlisting}
282void foo(monitor & mutex a) {
283
284
285
286        //Do Work
287        //...
288
289}
290
291void main() {
292        monitor a;
293
294
295
296        foo(a);
297
298}
299\end{lstlisting} &\begin{lstlisting}
300foo(& a) {
301
302
303
304        //Do Work
305        //...
306
307}
308
309main() {
310        monitor a;
311        //calling routine
312        //handles concurrency
313        acquire(a);
314        foo(a);
315        release(a);
316}
317\end{lstlisting} &\begin{lstlisting}
318foo(& a) {
319        //called routine
320        //handles concurrency
321        acquire(a);
322        //Do Work
323        //...
324        release(a);
325}
326
327main() {
328        monitor a;
329
330
331
332        foo(a);
333
334}
335\end{lstlisting}
336\end{tabular}
337\end{center}
338
339First of all, interaction between \code{otype} polymorphism and monitors is impossible since monitors do not support copying. Therefore, the main question is how to support \code{dtype} polymorphism. Since a monitor's main purpose is to ensure mutual exclusion when accessing shared data, this implies that mutual exclusion is only required for routines that do in fact access shared data. However, since \code{dtype} polymorphism always handles incomplete types (by definition), no \code{dtype} polymorphic routine can access shared data since the data requires knowledge about the type. Therefore, the only concern when combining \code{dtype} polymorphism and monitors is to protect access to routines. \Gls{callsite-locking} would require a significant amount of work, since any \code{dtype} routine may have to obtain some lock before calling a routine, depending on whether or not the type passed is a monitor. However, with \gls{entry-point-locking} calling a monitor routine becomes exactly the same as calling it from anywhere else.
340
341
342
343% ### #     # #######         #####   #####  #     # ####### ######
344%  #  ##    #    #           #     # #     # #     # #       #     #
345%  #  # #   #    #           #       #       #     # #       #     #
346%  #  #  #  #    #            #####  #       ####### #####   #     #
347%  #  #   # #    #    ###          # #       #     # #       #     #
348%  #  #    ##    #    ###    #     # #     # #     # #       #     #
349% ### #     #    #    ###     #####   #####  #     # ####### ######
350
351\subsection{Internal scheduling} \label{insched}
352Monitors also need to schedule waiting threads internally as a mean of synchronization. Internal scheduling is one of the simple examples of such a feature. It allows users to declare condition variables and have threads wait and signaled from them. Here is a simple example of such a technique :
353
354\begin{lstlisting}
355        mutex struct A {
356                condition e;
357        }
358
359        void foo(A & mutex a) {
360                //...
361                wait(a.e);
362                //...
363        }
364
365        void bar(A & mutex a) {
366                signal(a.e);
367        }
368\end{lstlisting}
369
370Note that in \CFA, \code{condition} have no particular need to be stored inside a monitor, beyond any software engineering reasons. Here routine \code{foo} waits for the \code{signal} from \code{bar} before making further progress, effectively ensuring a basic ordering. This semantic can easily be extended to multi-monitor calls by offering the same guarantee.
371\begin{center}
372\begin{tabular}{ c @{\hskip 0.65in} c }
373Thread 1 & Thread 2 \\
374\begin{lstlisting}
375void foo(monitor & mutex a,
376           monitor & mutex b) {
377        //...
378        wait(a.e);
379        //...
380}
381
382foo(a, b);
383\end{lstlisting} &\begin{lstlisting}
384void bar(monitor & mutex a,
385           monitor & mutex b) {
386        signal(a.e);
387}
388
389
390
391bar(a, b);
392\end{lstlisting}
393\end{tabular}
394\end{center}
395A direct extension of the single monitor semantics is to release all locks when waiting and transferring ownership of all locks when signalling. However, for the purpose of synchronization it may be usefull to only release some of the locks but keep others. It is possible to support internal scheduling and \gls{group-acquire} without any extra syntax by relying on order of acquisition. Here is an example of the different contexts in which internal scheduling can be used. (Note that here the use of helper routines is irrelevant, only routines acquire mutual exclusion have an impact on internal scheduling):
396
397\begin{center}
398\begin{tabular}{|c|c|c|}
399Context 1 & Context 2 & Context 3 \\
400\hline
401\begin{lstlisting}
402condition e;
403
404//acquire a & b
405void foo(monitor & mutex a,
406           monitor & mutex b) {
407
408        wait(e); //release a & b
409}
410
411
412
413
414
415
416foo(a,b);
417\end{lstlisting} &\begin{lstlisting}
418condition e;
419
420//acquire a
421void bar(monitor & mutex a,
422           monitor & nomutex b) {
423        foo(a,b);
424}
425
426//acquire a & b
427void foo(monitor & mutex a,
428           monitor & mutex b) {
429        wait(e);  //release a & b
430}
431
432bar(a, b);
433\end{lstlisting} &\begin{lstlisting}
434condition e;
435
436//acquire a
437void bar(monitor & mutex a,
438           monitor & nomutex b) {
439        baz(a,b);
440}
441
442//acquire b
443void baz(monitor & nomutex a,
444           monitor & mutex b) {
445        wait(e);  //release b
446}
447
448bar(a, b);
449\end{lstlisting}
450\end{tabular}
451\end{center}
452
453Context 1 is the simplest way of acquiring more than one monitor (\gls{group-acquire}), using a routine with multiple parameters having the \code{mutex} keyword. Context 2 also uses \gls{group-acquire} as well in routine \code{foo}. However, the routine is called by routine \code{bar}, which only acquires monitor \code{a}. Since monitors can be acquired multiple times this does not cause a deadlock by itself but it does force the acquiring order to \code{a} then \code{b}. Context 3 also forces the acquiring order to be \code{a} then \code{b} but does not use \gls{group-acquire}. The previous example tries to illustrate the semantics that must be established to support releasing monitors in a \code{wait} statement. In all cases, the behavior of the wait statment is to release all the locks that were acquired my the inner-most monitor call. That is \code{a & b} in context 1 and 2 and \code{b} only in context 3. Here are a few other examples of this behavior.
454
455
456\begin{center}
457\begin{tabular}{|c|c|c|}
458\begin{lstlisting}
459condition e;
460
461//acquire b
462void foo(monitor & nomutex a,
463           monitor & mutex b) {
464        bar(a,b);
465}
466
467//acquire a
468void bar(monitor & mutex a,
469           monitor & nomutex b) {
470
471        wait(e); //release a
472                  //keep b
473}
474
475foo(a, b);
476\end{lstlisting} &\begin{lstlisting}
477condition e;
478
479//acquire a & b
480void foo(monitor & mutex a,
481           monitor & mutex b) {
482        bar(a,b);
483}
484
485//acquire b
486void bar(monitor & mutex a,
487           monitor & nomutex b) {
488
489        wait(e); //release b
490                  //keep a
491}
492
493foo(a, b);
494\end{lstlisting} &\begin{lstlisting}
495condition e;
496
497//acquire a & b
498void foo(monitor & mutex a,
499           monitor & mutex b) {
500        bar(a,b);
501}
502
503//acquire none
504void bar(monitor & nomutex a,
505           monitor & nomutex b) {
506
507        wait(e); //release a & b
508                  //keep none
509}
510
511foo(a, b);
512\end{lstlisting}
513\end{tabular}
514\end{center}
515Note the right-most example is actually a trick pulled on the reader. Monitor state information is stored in thread local storage rather then in the routine context, which means that helper routines and other \code{nomutex} routines are invisible to the runtime system in regards to concurrency. This means that in the right-most example, the routine parameters are completly unnecessary. However, calling this routine from outside a valid monitor context is undefined.
516
517These semantics imply that in order to release of subset of the monitors currently held, users must write (and name) a routine that only acquires the desired subset and simply calls wait. While users can use this method, \CFA offers the \code{wait_release}\footnote{Not sure if an overload of \code{wait} would work...} which will release only the specified monitors. In the center previous examples, the code in the center uses the \code{bar} routine to only release monitor \code{b}. Using the \code{wait_release} helper, this can be rewritten without having the name two routines :
518\begin{center}
519\begin{tabular}{ c c c }
520\begin{lstlisting}
521        condition e;
522
523        //acquire a & b
524        void foo(monitor & mutex a,
525                   monitor & mutex b) {
526                bar(a,b);
527        }
528
529        //acquire b
530        void bar(monitor & mutex a,
531                   monitor & nomutex b) {
532
533                wait(e); //release b
534                          //keep a
535        }
536
537        foo(a, b);
538\end{lstlisting} &\begin{lstlisting}
539        =>
540\end{lstlisting} &\begin{lstlisting}
541        condition e;
542
543        //acquire a & b
544        void foo(monitor & mutex a,
545                   monitor & mutex b) {
546                wait_release(e,b); //release b
547                                         //keep a
548        }
549
550        foo(a, b);
551\end{lstlisting}
552\end{tabular}
553\end{center}
554
555Regardless of the context in which the \code{wait} statement is used, \code{signal} must be called holding the same set of monitors. In all cases, signal only needs a single parameter, the condition variable that needs to be signalled. But \code{signal} needs to be called from the same monitor(s) that call to \code{wait}. Otherwise, mutual exclusion cannot be properly transferred back to the waiting monitor.
556
557Finally, an additional semantic which can be very usefull is the \code{signal_block} routine. This routine behaves like signal for all of the semantics discussed above, but with the subtelty that mutual exclusion is transferred to the waiting task immediately rather than wating for the end of the critical section.
558\\
559
560% ####### #     # #######         #####   #####  #     # ####### ######
561% #        #   #     #           #     # #     # #     # #       #     #
562% #         # #      #           #       #       #     # #       #     #
563% #####      #       #            #####  #       ####### #####   #     #
564% #         # #      #    ###          # #       #     # #       #     #
565% #        #   #     #    ###    #     # #     # #     # #       #     #
566% ####### #     #    #    ###     #####   #####  #     # ####### ######
567\newpage
568\subsection{External scheduling} \label{extsched}
569An alternative to internal scheduling is to use external scheduling instead. This method is more constrained and explicit which may help users tone down the undeterministic nature of concurrency. Indeed, as the following examples demonstrates, external scheduling allows users to wait for events from other threads without the concern of unrelated events occuring. External scheduling can generally be done either in terms of control flow (ex: \uC) or in terms of data (ex: Go). Of course, both of these paradigms have their own strenghts and weaknesses but for this project control flow semantics where chosen to stay consistent with the rest of the languages semantics. Two challenges specific to \CFA arise when trying to add external scheduling with loose object definitions and multi-monitor routines. The following example shows a simple use \code{accept} versus \code{wait}/\code{signal} and its advantages.
570
571\begin{center}
572\begin{tabular}{|c|c|}
573Internal Scheduling & External Scheduling \\
574\hline
575\begin{lstlisting}
576        _Monitor blarg {
577                condition c;
578        public:
579                void f() { signal(c)}
580                void g() { wait(c); }
581        private:
582        }
583\end{lstlisting}&\begin{lstlisting}
584        _Monitor blarg {
585
586        public:
587                void f() { /*...*/ }
588                void g() { _Accept(f); }
589        private:
590        }
591\end{lstlisting}
592\end{tabular}
593\end{center}
594
595In the case of internal scheduling, the call to \code{wait} only guarantees that \code{g} is the last routine to access the monitor. This intails that the routine \code{f} may have acquired mutual exclusion several times while routine \code{h} was waiting. On the other hand, external scheduling guarantees that while routine \code{h} was waiting, no routine other than \code{g} could acquire the monitor.
596\\
597
598% #       ####### #######  #####  #######    ####### ######        #  #####
599% #       #     # #     # #     # #          #     # #     #       # #     #
600% #       #     # #     # #       #          #     # #     #       # #
601% #       #     # #     #  #####  #####      #     # ######        #  #####
602% #       #     # #     #       # #          #     # #     # #     #       #
603% #       #     # #     # #     # #          #     # #     # #     # #     #
604% ####### ####### #######  #####  #######    ####### ######   #####   #####
605
606\subsubsection{Loose object definitions}
607In \uC, monitor declarations include an exhaustive list of monitor operations. Since \CFA is not object oriented it becomes both more difficult to implement but also less clear for the user :
608
609\begin{lstlisting}
610        mutex struct A {};
611
612        void f(A & mutex a);
613        void g(A & mutex a) { accept(f); }
614\end{lstlisting}
615
616However, external scheduling is an example where implementation constraints become visible from the interface. Indeed, ince there is no hard limit to the number of threads trying to acquire a monitor concurrently, performance is a significant concern. Here is the pseudo code for the entering phase of a monitor :
617
618\begin{center}
619\begin{tabular}{l}
620\begin{lstlisting}[language=Pseudo]
621        if monitor is free :
622                enter
623        elif monitor accepts me :
624                enter
625        else :
626                block
627\end{lstlisting}
628\end{tabular}
629\end{center}
630
631For the \pseudo{monitor is free} condition it is easy to implement a check that can evaluate the condition in a few instruction. However, a fast check for \pseudo{monitor accepts me} is much harder to implement depending on the constraints put on the monitors. Indeed, monitors are often expressed as an entry queue and some acceptor queue as in the following figure :
632
633\begin{center}
634{\resizebox{0.4\textwidth}{!}{\input{monitor}}}
635\end{center}
636
637There are other alternatives to these pictures but in the case of this picture implementing a fast accept check is relatively easy. Indeed simply updating a bitmask when the acceptor queue changes is enough to have a check that executes in a single instruction, even with a fairly large number of acceptor. However, this relies on the fact that all the acceptable routines are declared with the monitor type. For OO languages this doesn't compromise much since monitors already have an exhaustive list of member routines. However, for \CFA this isn't the case, routines can be added to a type anywhere after its declaration. Its important to note that the bitmask approach does not actually require an exhaustive list of routines, but it requires a dense unique ordering of routines with an upper-bound and that ordering must be consistent across translation units.
638The alternative would be to have a picture more like this one:
639
640\begin{center}
641{\resizebox{0.4\textwidth}{!}{\input{ext_monitor}}}
642\end{center}
643
644Not storing the queues inside the monitor means that the storage can vary between routines, allowing for more flexibility and extensions. Storing an array of function-pointers would solve the issue of uniquely identifying acceptable routines. However, the single instruction bitmask compare has been replaced by dereferencing a pointer followed by a linear search. Furthermore, supporting nested external scheduling may now require additionnal searches on calls to accept to check if a routine is already queued in.
645
646At this point we must make a decision between flexibility and performance. Many design decisions in \CFA achieve both flexibility and performance, for example polymorphic routines add significant flexibility but inlining them means the optimizer can easily remove any runtime cost. Here however, the cost of flexibility cannot be trivially removed.
647
648In either cases here are a few alternatives for the different syntaxes this syntax : \\
649\begin{center}
650{\renewcommand{\arraystretch}{1.5}
651\begin{tabular}[t]{l @{\hskip 0.35in} l}
652\hline
653\multicolumn{2}{ c }{\code{accept} on type}\\
654\hline
655Alternative 1 & Alternative 2 \\
656\begin{lstlisting}
657mutex struct A
658accept( void f(A & mutex a) )
659{};
660\end{lstlisting} &\begin{lstlisting}
661mutex struct A {}
662accept( void f(A & mutex a) );
663
664\end{lstlisting} \\
665Alternative 3 & Alternative 4 \\
666\begin{lstlisting}
667mutex struct A {
668        accept( void f(A & mutex a) )
669};
670
671\end{lstlisting} &\begin{lstlisting}
672mutex struct A {
673        accept :
674                void f(A & mutex a) );
675};
676\end{lstlisting}\\
677\hline
678\multicolumn{2}{ c }{\code{accept} on routine}\\
679\hline
680\begin{lstlisting}
681mutex struct A {};
682
683void f(A & mutex a)
684
685accept( void f(A & mutex a) )
686void g(A & mutex a) {
687        /*...*/
688}
689\end{lstlisting}&\\
690\end{tabular}
691}
692\end{center}
693
694An other aspect to consider is what happens if multiple overloads of the same routine are used. For the time being it is assumed that multiple overloads of the same routine should be scheduled regardless of the overload used. However, this could easily be extended in the future.
695
696% #     # #     # #       ####### ###    #     # ####### #     #
697% ##   ## #     # #          #     #     ##   ## #     # ##    #
698% # # # # #     # #          #     #     # # # # #     # # #   #
699% #  #  # #     # #          #     #     #  #  # #     # #  #  #
700% #     # #     # #          #     #     #     # #     # #   # #
701% #     # #     # #          #     #     #     # #     # #    ##
702% #     #  #####  #######    #    ###    #     # ####### #     #
703
704\subsubsection{Multi-monitor scheduling}
705
706External scheduling, like internal scheduling, becomes orders of magnitude more complex when we start introducing multi-monitor syntax. Even in the simplest possible case some new semantics need to be established :
707\begin{lstlisting}
708        accept( void f(mutex struct A & mutex this))
709        mutex struct A {};
710
711        mutex struct B {};
712
713        void g(A & mutex a, B & mutex b) {
714                accept(f); //ambiguous, which monitor
715        }
716\end{lstlisting}
717
718The obvious solution is to specify the correct monitor as follows :
719
720\begin{lstlisting}
721        accept( void f(mutex struct A & mutex this))
722        mutex struct A {};
723
724        mutex struct B {};
725
726        void g(A & mutex a, B & mutex b) {
727                accept( f, b );
728        }
729\end{lstlisting}
730
731This is unambiguous. Both locks will be acquired and kept, when routine \code{f} is called the lock for monitor \code{a} will be temporarily transferred from \code{g} to \code{f} (while \code{g} still holds lock \code{b}). This behavior can be extended to multi-monitor accept statment as follows.
732
733\begin{lstlisting}
734        accept( void f(mutex struct A & mutex, mutex struct A & mutex))
735        mutex struct A {};
736
737        mutex struct B {};
738
739        void g(A & mutex a, B & mutex b) {
740                accept( f, b, a );
741        }
742\end{lstlisting}
743
744Note that the set of monitors passed to the \code{accept} statement must be entirely contained in the set of monitor already acquired in the routine. \code{accept} used in any other context is Undefined Behaviour.
745
746% ######  ####### #######    #    ### #        #####
747% #     # #          #      # #    #  #       #     #
748% #     # #          #     #   #   #  #       #
749% #     # #####      #    #     #  #  #        #####
750% #     # #          #    #######  #  #             #
751% #     # #          #    #     #  #  #       #     #
752% ######  #######    #    #     # ### #######  #####
753%
754%                #####  #     # ####### #     # #######  #####
755%             #     # #     # #       #     # #       #     #
756%             #     # #     # #       #     # #       #
757%    #####    #     # #     # #####   #     # #####    #####
758%             #   # # #     # #       #     # #             #
759%             #    #  #     # #       #     # #       #     #
760%                #### #  #####  #######  #####  #######  #####
761
762
763\subsubsection{Implementation Details: External scheduling queues}
764To support multi-monitor external scheduling means that some kind of entry-queues must be used that is aware of both monitors. However, acceptable routines must be aware of the entry queues which means they must be stored inside at least one of the monitors that will be acquired. This in turn adds the requirement a systematic algorithm of disambiguating which queue is relavant regardless of user ordering. The proposed algorithm is to fall back on monitors lock ordering and specify that the monitor that is acquired first is the lock with the relevant entry queue. This assumes that the lock acquiring order is static for the lifetime of all concerned objects but that is a reasonnable constraint. This algorithm choice has two consequences, the entry queue of the highest priority monitor is no longer a true FIFO queue and the queue of the lowest priority monitor is both required and probably unused. The queue can no longer be a FIFO queue because instead of simply containing the waiting threads in order arrival, they also contain the second mutex. Therefore, another thread with the same highest priority monitor but a different lowest priority monitor may arrive first but enter the critical section after a thread with the correct pairing. Secondly, since it may not be known at compile time which monitor will be the lowest priority monitor, every monitor needs to have the correct queues even though it is probable that half the multi-monitor queues will go unused for the entire duration of the program.
765
766\subsection{Other concurrency tools}
767TO BE CONTINUED...
768
769
770
771
772
773
774
775
776
777
778\newpage
779% ######     #    ######     #    #       #       ####### #       ###  #####  #     #
780% #     #   # #   #     #   # #   #       #       #       #        #  #     # ##   ##
781% #     #  #   #  #     #  #   #  #       #       #       #        #  #       # # # #
782% ######  #     # ######  #     # #       #       #####   #        #   #####  #  #  #
783% #       ####### #   #   ####### #       #       #       #        #        # #     #
784% #       #     # #    #  #     # #       #       #       #        #  #     # #     #
785% #       #     # #     # #     # ####### ####### ####### ####### ###  #####  #     #
786\section{Parallelism}
787Historically, computer performance was about processor speeds and instructions count. However, with heat dissipation being a direct consequence of speed increase, parallelism has become the new source for increased performance~\cite{Sutter05, Sutter05b}. In this decade, it is not longer reasonnable to create a high-performance application without caring about parallelism. Indeed, parallelism is an important aspect of performance and more specifically throughput and hardware utilization. The lowest-level approach of parallelism is to use \glspl{kthread} in combination with semantics like \code{fork}, \code{join}, etc. However, since these have significant costs and limitations, \glspl{kthread} are now mostly used as an implementation tool rather than a user oriented one. There are several alternatives to solve these issues that all have strengths and weaknesses. While there are many variations of the presented paradigms, most of these variations do not actually change the guarantees or the semantics, they simply move costs in order to achieve better performance for certain workloads.
788
789\subsection{User-level threads}
790A direct improvement on the \gls{kthread} approach is to use \glspl{uthread}. These threads offer most of the same features that the operating system already provide but can be used on a much larger scale. This approach is the most powerfull solution as it allows all the features of multi-threading, while removing several of the more expensives costs of using kernel threads. The down side is that almost none of the low-level threading problems are hidden, users still have to think about data races, deadlocks and synchronization issues. These issues can be somewhat alleviated by a concurrency toolkit with strong garantees but the parallelism toolkit offers very little to reduce complexity in itself.
791
792Examples of languages that support \glspl{uthread} are Erlang~\cite{Erlang} and \uC~\cite{uC++book}.
793
794\subsubsection{Fibers : user-level threads without preemption}
795A popular varient of \glspl{uthread} is what is often reffered to as \glspl{fiber}. However, \glspl{fiber} do not present meaningful semantical differences with \glspl{uthread}. Advocates of \glspl{fiber} list their high performance and ease of implementation as majors strenghts of \glspl{fiber} but the performance difference between \glspl{uthread} and \glspl{fiber} is controversial and the ease of implementation, while true, is a weak argument in the context of language design. Therefore this proposal largely ignore fibers.
796
797An example of a language that uses fibers is Go~\cite{Go}
798
799\subsection{Jobs and thread pools}
800The approach on the opposite end of the spectrum is to base parallelism on \glspl{pool}. Indeed, \glspl{pool} offer limited flexibility but at the benefit of a simpler user interface. In \gls{pool} based systems, users express parallelism as units of work and a dependency graph (either explicit or implicit) that tie them together. This approach means users need not worry about concurrency but significantly limits the interaction that can occur among jobs. Indeed, any \gls{job} that blocks also blocks the underlying worker, which effectively means the CPU utilization, and therefore throughput, suffers noticeably. It can be argued that a solution to this problem is to use more workers than available cores. However, unless the number of jobs and the number of workers are comparable, having a significant amount of blocked jobs always results in idles cores.
801
802The gold standard of this implementation is Intel's TBB library~\cite{TBB}.
803
804\subsection{Paradigm performance}
805While the choice between the three paradigms listed above may have significant performance implication, it is difficult to pindown the performance implications of chosing a model at the language level. Indeed, in many situations one of these paradigms may show better performance but it all strongly depends on the workload. Having a large amount of mostly independent units of work to execute almost guarantess that the \gls{pool} based system has the best performance thanks to the lower memory overhead. However, interactions between jobs can easily exacerbate contention. User-level threads allow fine-grain context switching, which results in better resource utilisation, but context switches will be more expansive and the extra control means users need to tweak more variables to get the desired performance. Furthermore, if the units of uninterrupted work are large enough the paradigm choice is largely amorticised by the actual work done.
806
807%  #####  #######    #          ####### ######  ######
808% #     # #         # #            #    #     # #     #
809% #       #        #   #           #    #     # #     #
810% #       #####   #     # #####    #    ######  ######
811% #       #       #######          #    #     # #     #
812% #     # #       #     #          #    #     # #     #
813%  #####  #       #     #          #    ######  ######
814
815\section{\CFA 's Thread Building Blocks}
816As a system-level language, \CFA should offer both performance and flexibilty as its primary goals, simplicity and user-friendliness being a secondary concern. Therefore, the core of parallelism in \CFA should prioritize power and efficiency. With this said, deconstructing popular paradigms in order to get simple building blocks yields \glspl{uthread} as the core parallelism block. \Glspl{pool} and other parallelism paradigms can then be built on top of the underlying threading model.
817
818\subsection{Coroutines : A stepping stone}\label{coroutine}
819While the main focus of this proposal is concurrency and paralellism, it is important to adress coroutines which are actually a significant underlying aspect of the concurrency system. Indeed, while having nothing todo with parallelism and arguably very little to do with concurrency, coroutines need to deal with context-switchs and and other context management operations. Therefore, this proposal includes coroutines both as an intermediate step for the implementation of threads and a first class feature of \CFA.
820
821The core API of coroutines revolve around two features : independent stacks and \code{suspend}/\code{resume}.
822Here is an example of a solution to the fibonnaci problem using \CFA coroutines :
823\begin{lstlisting}
824        struct Fibonacci {
825              int fn; // used for communication
826              coroutine_descriptor c;
827        };
828
829        void ?{}(Fibonacci* this) {
830              this->fn = 0;
831        }
832
833        coroutine_descriptor* get_¶coroutine¶(Fibonacci* this) {
834              return &this->c;
835        }
836
837        void co_main(Fibonacci* this) {
838                int fn1, fn2;           // retained between resumes
839                this->fn = 0;
840                fn1 = this->fn;
841                suspend(this);          // return to last resume
842
843                this->fn = 1;
844                fn2 = fn1;
845                fn1 = this->fn;
846                suspend(this);          // return to last resume
847
848                for ( ;; ) {
849                        this->fn = fn1 + fn2;
850                        fn2 = fn1;
851                        fn1 = this->fn;
852                        suspend(this);  // return to last resume
853                }
854        }
855
856        int next(Fibonacci* this) {
857                resume(this); // transfer to last suspend
858                return this.fn;
859        }
860
861        void main() {
862                Fibonacci f1, f2;
863                for ( int i = 1; i <= 10; i += 1 ) {
864                        sout | next(&f1) | '§\verb+ +§' | next(&f2) | endl;
865                }
866        }
867\end{lstlisting}
868
869\subsubsection{Construction}
870One important design challenge for coroutines and threads (shown in section \ref{threads}) is that the runtime system needs to run some code after the user-constructor runs. In the case of the coroutines this challenge is simpler since there is no loss of determinism brough by preemption or scheduling, however, the underlying challenge remains the same for coroutines and threads.
871
872The runtime system needs to create the coroutine's stack and more importantly prepare it for the first resumption. The timing of the creation is non trivial since users both expect to have fully constructed objects once the main is called and to be able to resume the coroutine from the main (Obviously we only solve cases where these two statements don't conflict). There are several solutions to this problem but the chosen options effectively forces the design of the coroutine.
873
874Furthermore, \CFA faces an extra challenge which is that polymorphique routines rely on invisible thunks when casted to non-polymorphic routines and these thunks have function scope, for example :
875
876TODO : Simple case where a thunk would be created.
877
878
879
880\subsubsection{Alternative: Inheritance}
881One solution to this challenge would be to use inheritence,
882
883\begin{lstlisting}
884        struct Fibonacci {
885              int fn; // used for communication
886              coroutine c;
887        };
888
889        void ?{}(Fibonacci* this) {
890              this->fn = 0;
891                (&this->c){};
892        }
893\end{lstlisting}
894
895There are two downsides to the approach. The first, which is relatively minor, is that the base class needs to be made aware of the main routine pointer, regardless of whether we use a parameter or a virtual pointer, this means the coroutine data must be made larger to store a value that is actually a compile time constant (The address of the main routine). The second problem which is both subtle but significant, is that now can get the initialisation order of there coroutines wrong. Indeed, every field of a \CFA struct will be constructed but in the order of declaration, unless users explicitly write otherwise. This means that users who forget to initialize a the coroutine at the right time may resume the coroutine at with an uninitilized object. For coroutines, this is unlikely to be a problem, for threads however, this is a significant problem.
896
897\subsubsection{Alternative: Reserved keyword}
898The next alternative is to use language support to annotate coroutines as follows :
899
900\begin{lstlisting}
901        coroutine struct Fibonacci {
902              int fn; // used for communication
903        };
904\end{lstlisting}
905
906This mean the compiler can solve problems by injecting code where needed. The downside of this approach is that it makes coroutine a special case in the language. Users who would want to extend coroutines or build their own for various reasons can only do so in ways offered by the language. Furthermore, implementing coroutines without language supports also displays the power of \CFA.
907
908\subsubsection{Alternative: Lamda Objects}
909
910Boost does not use objects...
911TO BE CONTINUED...
912
913\subsubsection{Trait based coroutines}
914
915Finally the approach chosen, which is the one closest to \CFA idioms, is to use trait-based lazy coroutines, the approach shown in section \ref{coroutine}. This approach defines a coroutine as anything that satisfies the \code{is_coroutine} and is used as a coroutine is a coroutine. This entails the an object is not a coroutine until \code{resume} (and \code{prime}) is called on the object. Correspondingly, any object that is passed to \code{resume} is a coroutine since it must satisfy the \code{is_coroutine} trait to compile.
916
917% ####### #     # ######  #######    #    ######   #####
918%    #    #     # #     # #         # #   #     # #     #
919%    #    #     # #     # #        #   #  #     # #
920%    #    ####### ######  #####   #     # #     #  #####
921%    #    #     # #   #   #       ####### #     #       #
922%    #    #     # #    #  #       #     # #     # #     #
923%    #    #     # #     # ####### #     # ######   #####
924
925\subsection{Thread Interface}\label{threads}
926The basic building blocks of \CFA are \glspl{cfathread}. By default these are implemented as \glspl{uthread}, and as such, offer a flexible and lightweight threading interface (lightweight compared to \glspl{kthread}). A thread can be declared using a struct declaration with prefix \code{thread} as follows :
927
928\begin{lstlisting}
929        trait is_¶thread¶(dtype T) {
930                void co_main(T* this);
931                coroutine* get_coroutine(T* this);
932        };
933
934        thread struct foo {};
935\end{lstlisting}
936
937Obviously, for this thread implementation to be usefull it must run some user code. Several other threading interfaces use a function-pointer representation as the interface of threads (for example : \Csharp~\cite{Csharp} and Scala~\cite{Scala}). However, this proposal considers that statically tying a \code{main} routine to a thread superseeds this approach. Since the \code{main} routine is already a special routine in \CFA (where the program begins), the existing syntax for declaring routines names with special semantics can be extended, i.e. operator overloading. As such the \code{main} routine of a thread can be defined as :
938\begin{lstlisting}
939        thread struct foo {};
940
941        void ?main(foo* this) {
942                sout | "Hello World!" | endl;
943        }
944\end{lstlisting}
945
946In this example, threads of type \code{foo} will start there execution in the \code{void ?main(foo*)} routine which in this case prints \code{"Hello World!"}. While this proposoal encourages this approach which is enforces strongly type programming. Users may prefer to use the routine based thread semantics for the sake of simplicity. With these semantics it is trivial to write a thread type that takes a function pointer as parameter and executes it on its stack asynchronously :
947\begin{lstlisting}
948        typedef void (*voidFunc)(void);
949
950        thread struct FuncRunner {
951                voidFunc func;
952        };
953
954        //ctor
955        void ?{}(FuncRunner* this, voidFunc inFunc) {
956                func = inFunc;
957        }
958
959        //main
960        void t_main(FuncRunner* this) {
961                this->func();
962        }
963\end{lstlisting}
964
965Of course for threads to be useful, it must be possible to start and stop threads and wait for them to complete execution. While using an \acrshort{api} such as \code{fork} and \code{join} is relatively common in the literature, such an interface is unnecessary. Indeed, the simplest approach is to use \acrshort{raii} principles and have threads \code{fork} once the constructor has completed and \code{join} before the destructor runs.
966\begin{lstlisting}
967thread struct World; //FuncRunner declared above
968
969void ?main(thread World* this) {
970        sout | "World!" | endl;
971}
972
973void main() {
974        World w;
975        //Thread run forks here
976
977        //Print to "Hello " and "World!" will be run concurrently
978        sout | "Hello " | endl;
979
980        //Implicit join at end of scope
981}
982\end{lstlisting}
983This semantic has several advantages over explicit semantics : typesafety is guaranteed, a thread is always started and stopped exaclty once and users cannot make any progamming errors. However, one of the apparent drawbacks of this system is that threads now always form a lattice, that is they are always destroyed in opposite order of construction. While this seems like a significant limitation, existing \CFA semantics can solve this problem. Indeed, by using dynamic allocation to create threads will naturally let threads outlive the scope in which the thread was created much like dynamically allocating memory will let objects outlive the scope in which thy were created :
984
985\begin{lstlisting}
986        thread struct MyThread {
987                //...
988        };
989
990        //ctor
991        void ?{}(MyThread* this,
992                     bool is_special = false) {
993                //...
994        }
995
996        //main
997        void ?main(MyThread* this) {
998                //...
999        }
1000
1001        void foo() {
1002                MyThread* special_thread;
1003                {
1004                        MyThread thrds = {false};
1005                        //Start a thread at the beginning of the scope
1006
1007                        DoStuff();
1008
1009                        //create a other thread that will outlive the thread in this scope
1010                        special_thread = new MyThread{true};
1011
1012                        //Wait for the thread to finish
1013                }
1014                DoMoreStuff();
1015
1016                //Now wait for the special
1017        }
1018\end{lstlisting}
1019
1020Another advantage of this semantic is that it naturally scale to multiple threads meaning basic synchronisation is very simple :
1021
1022\begin{lstlisting}
1023        thread struct MyThread {
1024                //...
1025        };
1026
1027        //ctor
1028        void ?{}(MyThread* this) {}
1029
1030        //main
1031        void ?main(MyThread* this) {
1032                //...
1033        }
1034
1035        void foo() {
1036                MyThread thrds[10];
1037                //Start 10 threads at the beginning of the scope
1038
1039                DoStuff();
1040
1041                //Wait for the 10 threads to finish
1042        }
1043\end{lstlisting}
1044
1045\newpage
1046\bf{WORK IN PROGRESS}
1047\subsection{The \CFA Kernel : Processors, Clusters and Threads}\label{kernel}
1048
1049
1050\subsection{Paradigms}\label{cfaparadigms}
1051Given these building blocks we can then reproduce the all three of the popular paradigms. Indeed, we get \glspl{uthread} as the default paradigm in \CFA. However, disabling \glspl{preemption} on the \gls{cfacluster} means \glspl{cfathread} effectively become \glspl{fiber}. Since several \glspl{cfacluster} with different scheduling policy can coexist in the same application, this allows \glspl{fiber} and \glspl{uthread} to coexist in the runtime of an application.
1052
1053% \subsection{High-level options}\label{tasks}
1054%
1055% \subsubsection{Thread interface}
1056% constructors destructors
1057%       initializer lists
1058% monitors
1059%
1060% \subsubsection{Futures}
1061%
1062% \subsubsection{Implicit threading}
1063% Finally, simpler applications can benefit greatly from having implicit parallelism. That is, parallelism that does not rely on the user to write concurrency. This type of parallelism can be achieved both at the language level and at the system level.
1064%
1065% \begin{center}
1066% \begin{tabular}[t]{|c|c|c|}
1067% Sequential & System Parallel & Language Parallel \\
1068% \begin{lstlisting}
1069% void big_sum(int* a, int* b,
1070%                int* out,
1071%                size_t length)
1072% {
1073%       for(int i = 0; i < length; ++i ) {
1074%               out[i] = a[i] + b[i];
1075%       }
1076% }
1077%
1078%
1079%
1080%
1081%
1082% int* a[10000];
1083% int* b[10000];
1084% int* c[10000];
1085% //... fill in a and b ...
1086% big_sum(a, b, c, 10000);
1087% \end{lstlisting} &\begin{lstlisting}
1088% void big_sum(int* a, int* b,
1089%                int* out,
1090%                size_t length)
1091% {
1092%       range ar(a, a + length);
1093%       range br(b, b + length);
1094%       range or(out, out + length);
1095%       parfor( ai, bi, oi,
1096%       [](int* ai, int* bi, int* oi) {
1097%               oi = ai + bi;
1098%       });
1099% }
1100%
1101% int* a[10000];
1102% int* b[10000];
1103% int* c[10000];
1104% //... fill in a and b ...
1105% big_sum(a, b, c, 10000);
1106% \end{lstlisting}&\begin{lstlisting}
1107% void big_sum(int* a, int* b,
1108%                int* out,
1109%                size_t length)
1110% {
1111%       for (ai, bi, oi) in (a, b, out) {
1112%               oi = ai + bi;
1113%       }
1114% }
1115%
1116%
1117%
1118%
1119%
1120% int* a[10000];
1121% int* b[10000];
1122% int* c[10000];
1123% //... fill in a and b ...
1124% big_sum(a, b, c, 10000);
1125% \end{lstlisting}
1126% \end{tabular}
1127% \end{center}
1128%
1129% \subsection{Machine setup}\label{machine}
1130% Threads are all good and well but wee still some OS support to fully utilize available hardware.
1131%
1132% \textbf{\large{Work in progress...}} Do wee need something beyond specifying the number of kernel threads?
1133
1134%    #    #       #
1135%   # #   #       #
1136%  #   #  #       #
1137% #     # #       #
1138% ####### #       #
1139% #     # #       #
1140% #     # ####### #######
1141\section{Putting it all together}
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152% ####### #     # ####### #     # ######  #######
1153% #       #     #    #    #     # #     # #
1154% #       #     #    #    #     # #     # #
1155% #####   #     #    #    #     # ######  #####
1156% #       #     #    #    #     # #   #   #
1157% #       #     #    #    #     # #    #  #
1158% #        #####     #     #####  #     # ######
1159\section{Future work}
1160Concurrency and parallelism is still a very active field that strongly benefits from hardware advances. As such certain features that aren't necessarily mature enough in their current state could become relevant in the lifetime of \CFA.
1161\subsection{Transactions}
1162
1163% ####### #     # ######
1164% #       ##    # #     #
1165% #       # #   # #     #
1166% #####   #  #  # #     #
1167% #       #   # # #     #
1168% #       #    ## #     #
1169% ####### #     # ######
1170\section*{Acknowledgements}
1171
1172\clearpage
1173\printglossary[type=\acronymtype]
1174\printglossary
1175
1176\clearpage
1177\bibliographystyle{plain}
1178\bibliography{cw92,distSharedMem,lfp92,mlw92,parallel,parallelIO,partheory,pl,pldi92,ps,realtime,techreportsPAB,visual,local}
1179
1180
1181\end{document}
Note: See TracBrowser for help on using the repository browser.