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

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

Finished reviewing concurrency section v0.4

  • Property mode set to 100644
File size: 42.5 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{common}                                          % 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 \\
88Dept. of Computer Science, University of Waterloo, \\ Waterloo, Ontario, Canada
89}
90
91\maketitle
92\section{Introduction}
93This proposal provides a minimal core concurrency API that is both simple, efficient and can be reused to build higher-level features. The simplest possible 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 construct as the basis of the concurrency in \CFA.
94Indeed, for highly productive parallel programming high-level approaches are much more popular\cite{HPP:Study}. Examples are task based parallelism, message passing, implicit threading.
95
96There are actually two problems that need to be solved in the design of the concurrency for a 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.
97
98\section{Concurrency}
99Several 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 rely on message passing or other paradigms that often closely relate to networking concepts. However, in imperative or OO languages, these approaches entail a clear distinction between concurrent and non-concurrent paradigms (i.e. message passing versus routine call). Which in turns mean that programmers need to learn two sets of designs patterns in order to be effective. Approaches based on shared memory are more closely related to non-concurrent paradigms since they often rely on non-concurrent constructs like routine calls and objects. At a lower level these can be implemented as locks and atomic operations. However, for productivity reasons it is desireable to have a higher-level construct to be the core concurrency paradigm\cite{HPP:Study}. This project proposes Monitors\cite{Hoare74} as the core concurrency construct.
100\\
101
102Finally, an approach that is worth mentionning because it is gaining in popularity is transactionnal memory\cite{Dice10}. However, the performance and feature set is currently too restrictive to be possible 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.
103
104\subsection{Monitors}
105A 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 :
106\begin{lstlisting}
107        typedef /*some monitor type*/ monitor;
108        int f(monitor & m);
109
110        int main() {
111                monitor m;
112                f(m);
113        }
114\end{lstlisting}
115
116\subsubsection{Call semantics} \label{call}
117The above example of monitors already displays some of their intrinsic caracteristics. 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.
118\\
119
120Another aspect to consider is when a monitor acquires its mutual exclusion. Indeed, a monitor may need to be passed through multiple helper routines that do not acquire the monitor mutual exclusion on entry. Examples of this can be both generic helper routines (\code{swap}, \code{sort}, etc.) or specific helper routines like the following example :
121
122\begin{lstlisting}
123        mutex struct counter_t { /*...*/ };
124
125        void ?{}(counter_t & nomutex this);
126        int ++?(counter_t & mutex this);
127        void ?{}(Int * this, counter_t & mutex cnt);
128\end{lstlisting}
129*semantics of the declaration of \code{mutex struct counter_t} are discussed in details in section \ref{data}
130\\
131
132This example is of a monitor implementing an atomic counter. Here, the constructor uses the \code{nomutex} keyword to signify that it does not acquire the coroutine mutual exclusion when constructing. This is because object not yet constructed should never be shared and therefore do not require mutual exclusion. The prefix increment operator
133uses \code{mutex} to protect the incrementing process from race conditions. Finally, we have a conversion operator from \code{counter_t} to \code{Int}. This conversion may or may not require the \code{mutex} key word depending whether or not reading an \code{Int} is an atomic operation or not.
134\\
135
136Having 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. If there were a meaning to routine \code{void foo(counter_t & this)} then one could argue that it should be to 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 this is the more "normal" behavior, \code{nomutex} effectively stating explicitly that "this routine has nothing special". An other alternative is to make 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 more clearly 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 will be used for the sake of clarity.
137\\
138
139Regardless of which keyword is kept, it is important to establish when mutex/nomutex may be used depending on type parameters.
140\begin{lstlisting}
141        int f1(monitor & mutex m);
142        int f2(const monitor & mutex m);
143        int f3(monitor ** mutex m);
144        int f4(monitor *[] mutex m);
145        int f5(graph(monitor*) & mutex m);
146\end{lstlisting}
147
148The problem is to indentify which object(s) should be acquired. Furthermore we also need to acquire each objects only once. In case of simple routines like \code{f1} and \code{f2} it is easy to identify an exhaustive list of objects to acquire on entering. Adding indirections (\code{f3}) still allows the compiler and programmer to indentify which object will be acquired. However, adding in arrays (\code{f4}) makes it much harder. Array lengths aren't 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 custom 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).
149
150\subsubsection{Data semantics} \label{data}
151Once 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 appripriate protection. For example here is a more fleshed-out version of the counter showed in \ref{call}:
152\begin{lstlisting}
153        mutex struct counter_t {
154                int value;
155        };
156
157        void ?{}(counter_t & nomutex this) {
158                this.cnt = 0;
159        }
160
161        int ++?(counter_t & mutex this) {
162                return ++this->value;
163        }
164
165        void ?{}(int * this, counter_t & mutex cnt) {
166                *this = (int)cnt;
167        }
168\end{lstlisting}
169\begin{tabular}{ c c }
170Thread 1 & Thread 2 \\
171\begin{lstlisting}
172        void f(counter_t & mutex c) {
173                for(;;) {
174                        sout | (int)c | endl;
175                }
176        }
177\end{lstlisting} &\begin{lstlisting}
178        void g(counter_t & mutex c) {
179                for(;;) {
180                        ++c;
181                }
182        }
183
184\end{lstlisting}
185\end{tabular}
186\\
187
188
189This simple counter offers an example of monitor usage. Notice how the counter is used without any explicit synchronisation and yet supports thread-safe semantics for both reading and writting. \\
190
191These simple mutual exclusion semantics also naturally expand to multi-monitor calls.
192\begin{lstlisting}
193        int f(MonitorA & mutex a, MonitorB & mutex b);
194
195        MonitorA a;
196        MonitorB b;
197        f(a,b);
198\end{lstlisting}
199
200This code acquires both locks before entering the critical section. In practice, writing multi-locking routines that can not lead to deadlocks can be very tricky. Having language level support for such feature is therefore a significant asset for \CFA. However, this does have significant repercussions relating to scheduling (see \ref{insched} and \ref{extsched}). Furthermore, the ability to acquire multiple monitors at the same time does incur a significant pitfall even without looking into scheduling. For example :
201\begin{lstlisting}
202        void foo(A & mutex a, B & mutex a) {
203                //...
204        }
205
206        void bar(A & mutex a, B & nomutex a)
207                //...
208                foo(a, b);
209                //...
210        }
211
212        void baz(A & nomutex a, B & mutex a)
213                //...
214                foo(a, b);
215                //...
216        }
217\end{lstlisting}
218
219Recursive mutex routine calls are allowed in \CFA but if not done carefully it can lead to nested monitor call problems\cite{Lister77}. These problems which are a specific  implementation of the lock acquiring order problem. In the example above, the user uses implicit ordering in the case of function \code{bar} but explicit ordering in the case of \code{baz}. This subtle mistake can mean that calling these two functions concurrently will lead to deadlocks, depending on the implicit ordering matching the explicit ordering. As shown on several occasion\cit, there isn't really any solutions to this problem, users simply need to be carefull when acquiring multiple monitors at the same time.
220
221\subsubsection{Implementation Details: Interaction with polymorphism}
222At first glance, interaction between monitors and \CFA's concept of polymorphism seem complexe to support. However, it can be reasoned that entry-point locking can solve most of the issues that could be present with polymorphism.
223
224First 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. We must remember that monitors' 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 handle incomplete types (by definition) no \code{dtype} polymorphic routine can access shared data since the data would require knowledge about the type. Therefore the only concern when combining \code{dtype} polymorphism and monitors is to protect access to routines. With callsite-locking, this would require significant amount of work since any \code{dtype} routine could have to obtain some lock before calling a routine. However, with entry-point-locking calling a monitor routine becomes exactly the same as calling it from anywhere else.
225
226\subsection{Internal scheduling} \label{insched}
227Monitors should also be able to schedule what threads access it 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 wait for them to be signaled. Here is a simple example of such a technique :
228
229\begin{lstlisting}
230        mutex struct A {
231                condition e;
232        }
233
234        void foo(A & mutex a) {
235                //...
236                wait(a.e);
237                //...
238        }
239
240        void bar(A & mutex a) {
241                signal(a.e);
242        }
243\end{lstlisting}
244
245Here routine \code{foo} waits on 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.
246
247\begin{center}
248\begin{tabular}{ c @{\hskip 0.65in} c }
249Thread 1 & Thread 2 \\
250\begin{lstlisting}
251void foo(monitor & mutex a,
252         monitor & mutex b) {
253        //...
254        wait(a.e);
255        //...
256}
257
258foo(a, b);
259\end{lstlisting} &\begin{lstlisting}
260void bar(monitor & mutex a,
261         monitor & mutex b) {
262        signal(a.e);
263}
264
265
266
267bar(a, b);
268\end{lstlisting}
269\end{tabular}
270\end{center}
271
272A direct extension of the single monitor semantics would be 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. On the technical side, partially releasing lock is feasible but from the user perspective a choice must be made for the syntax of this feature. It is possible to do without any extra syntax by relying on order of acquisition (Note that here the use of helper routines is irrelevant, only routines the acquire mutual exclusion have an impact on internal scheduling):
273
274\begin{center}
275\begin{tabular}{|c|c|c|}
276Context 1 & Context 2 & Context 3 \\
277\hline
278\begin{lstlisting}
279condition e;
280
281void foo(monitor & mutex a,
282         monitor & mutex b) {
283        wait(e);
284}
285
286
287
288
289
290
291foo(a,b);
292\end{lstlisting} &\begin{lstlisting}
293condition e;
294
295void bar(monitor & mutex a,
296         monitor & nomutex b) {
297        foo(a,b);
298}
299
300void foo(monitor & mutex a,
301         monitor & mutex b) {
302        wait(e);
303}
304
305bar(a, b);
306\end{lstlisting} &\begin{lstlisting}
307condition e;
308
309void bar(monitor & mutex a,
310         monitor & nomutex b) {
311        foo(a,b);
312}
313
314void baz(monitor & nomutex a,
315         monitor & mutex b) {
316        wait(e);
317}
318
319bar(a, b);
320\end{lstlisting}
321\end{tabular}
322\end{center}
323
324This can be interpreted in two different ways :
325\begin{flushleft}
326\begin{enumerate}
327        \item \code{wait} atomically releases the monitors acquired by the inner-most routine, \underline{ignoring} nested calls.
328        \item \code{wait} atomically releases the monitors acquired by the inner-most routine, \underline{considering} nested calls.
329\end{enumerate}
330\end{flushleft}
331While the difference between these two is subtle, it has a significant impact. In the first case it means that the calls to \code{foo} would behave the same in Context 1 and 2. This semantic would also mean that the call to \code{wait} in routine \code{baz} would only release \code{monitor b}. While this may seem intuitive with these examples, it does have one significant implication, it creates a strong distinction between acquiring multiple monitors in sequence and acquiring the same monitors simulatenously, i.e. :
332
333\begin{center}
334\begin{tabular}{c @{\hskip 0.35in} c @{\hskip 0.35in} c}
335\begin{lstlisting}
336enterMonitor(a);
337enterMonitor(b);
338// do stuff
339leaveMonitor(b);
340leaveMonitor(a);
341\end{lstlisting} & != &\begin{lstlisting}
342enterMonitor(a);
343enterMonitor(a, b);
344// do stuff
345leaveMonitor(a, b);
346leaveMonitor(a);
347\end{lstlisting}
348\end{tabular}
349\end{center}
350
351This is not intuitive because even if both methods display the same monitors state both inside and outside the critical section respectively, the behavior is different. Furthermore, the actual acquiring order will be exaclty the same since acquiring a monitor from inside its mutual exclusion is a no-op. This means that even if the data and the actual control flow are the same using both methods, the behavior of the \code{wait} will be different. The alternative is option 2, that is releasing acquired monitors, \underline{considering} nesting. This solves the issue of having the two acquiring method differ at the cost of making routine \code{foo} behave differently depending on from which context it is called (Context 1 or 2). Indeed in Context 2, routine \code{foo} actually behaves like routine \code{baz} rather than having the same behavior than in Context 1. The fact that both implicit approaches can be unintuitive depending on the perspective may be a sign that the explicit approach is superior. For this reason this \CFA does not support implicit monitor releasing and uses explicit semantics.
352\\
353
354The following examples shows three alternatives of explicit wait semantics :
355\\
356
357\begin{center}
358\begin{tabular}{|c|c|c|}
359Case 1 & Case 2 & Case 3 \\
360Branding on construction & Explicit release list & Explicit ignore list \\
361\hline
362\begin{lstlisting}
363void foo(monitor & mutex a,
364         monitor & mutex b,
365           condition & c)
366{
367        // Releases monitors
368        // branded in ctor
369        wait(c);
370}
371
372monitor a;
373monitor b;
374condition1 c1 = {a};
375condition2 c2 = {a, b};
376
377//Will release only a
378foo(a,b,c1);
379
380//Will release a and b
381foo(a,b,c2);
382\end{lstlisting} &\begin{lstlisting}
383void foo(monitor & mutex a,
384         monitor & mutex b,
385           condition & c)
386{
387        // Releases monitor a
388        // Holds monitor b
389        waitRelease(c, [a]);
390}
391
392monitor a;
393monitor b;
394condition c;
395
396
397
398foo(a,b,c);
399
400
401
402\end{lstlisting} &\begin{lstlisting}
403void foo(monitor & mutex a,
404         monitor & mutex b,
405           condition & c)
406{
407        // Releases monitor a
408        // Holds monitor b
409        waitHold(c, [b]);
410}
411
412monitor a;
413monitor b;
414condition c;
415
416
417
418foo(a,b,c);
419
420
421
422\end{lstlisting}
423\end{tabular}
424\end{center}
425(Note : Case 2 and 3 use tuple semantics to pass a variable length list of elements.)
426\\
427
428All these cases have their pros and cons. Case 1 is more distinct because it means programmers need to be carefull about where the condition is initialized as well as where it is used. On the other hand, it is very clear and explicitly states which monitor is released and which monitor stays acquired. This is similar to Case 2, which releases only the monitors explictly listed. However, in Case 2, calling the \code{wait} routine instead of the \code{waitRelease} routine releases all the acquired monitor. The Case 3 is an improvement on that since it releases all the monitors except those specified. The result is that the \code{wait} routine can be written as follows :
429\begin{lstlisting}
430void wait(condition & cond) {
431        waitHold(cond, []);
432}
433\end{lstlisting}
434This alternative offers nice and consistent behavior between \code{wait} and \code{waitHold}. However, one large pitfall is that mutual exclusion can now be violated by calls to library code. Indeed, even if the following example seems benign there is one significant problem :
435\begin{lstlisting}
436monitor global;
437
438extern void doStuff(); //uses global
439
440void foo(monitor & mutex m) {
441        //...
442        doStuff(); //warning can release monitor m
443        //...
444}
445
446foo(global);
447\end{lstlisting}
448
449Indeed, if Case 2 or 3 are chosen it any code can violate the mutual exclusion of the calling code by issuing calls to \code{wait} or \code{waitHold} in a nested monitor context. Case 2 can be salvaged by removing the \code{wait} routine from the API but Case 3 cannot prevent users from calling \code{waitHold(someCondition, [])}. For this reason the syntax proposed in Case 3 is rejected. Note that the syntax proposed in case 1 and 2 are not exclusive. Indeed, by supporting two types of condition both cases can be supported :
450\begin{lstlisting}
451struct condition { /*...*/ };
452
453// Second argument is a variable length tuple.
454void wait(condition & cond, [...] monitorsToRelease);
455void signal(condition & cond);
456
457struct conditionN { /*...*/ };
458
459void ?{}(conditionN* this, /*list of N monitors to release*/);
460void wait(conditionN & cond);
461void signal(conditionN & cond);
462\end{lstlisting}
463
464Regardless of the option chosen for wait semantics, signal must be symmetrical. 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.
465
466Finally, an additionnal semantic which can be very usefull is the \code{signalBlock} 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.
467\\
468
469\subsection{External scheduling} \label{extsched}
470As one might expect, the alternative to Internal scheduling is to use External scheduling instead. This method is somewhat more robust to deadlocks since one of the threads keeps a relatively tight control on scheduling. Indeed, as the following examples will demonstrate, 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 what a simple use \code{accept} versus \code{wait}/\code{signal} and its advantages.
471
472\begin{center}
473\begin{tabular}{|c|c|}
474Internal Scheduling & External Scheduling \\
475\hline
476\begin{lstlisting}
477        _Monitor blarg {
478                condition c;
479        public:
480                void f() { signal(c)}
481                void g() { wait(c); }
482        private:
483        }
484\end{lstlisting}&\begin{lstlisting}
485        _Monitor blarg {
486
487        public:
488                void f();
489                void g() { _Accept(f); }
490        private:
491        }
492\end{lstlisting}
493\end{tabular}
494\end{center}
495
496In the case of internal scheduling, the call to \code{wait} only guarantees that \code{g} was 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.
497\\
498
499\subsubsection{Loose object definitions}
500In \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 :
501
502\begin{lstlisting}
503        mutex struct A {};
504
505        void f(A & mutex a);
506        void g(A & mutex a) { accept(f); }
507\end{lstlisting}
508
509However, 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 :
510
511\begin{center}
512\begin{tabular}{l}
513\begin{lstlisting}[language=Pseudo]
514        if monitor is free :
515                enter
516        elif monitor accepts me :
517                enter
518        else :
519                block
520\end{lstlisting}
521\end{tabular}
522\end{center}
523
524For 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 :
525
526\begin{center}
527{\resizebox{0.4\textwidth}{!}{\input{monitor}}}
528\end{center}
529
530There 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.
531The alternative would be to have a picture more like this one:
532
533\begin{center}
534{\resizebox{0.4\textwidth}{!}{\input{ext_monitor}}}
535\end{center}
536
537Not 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.
538
539At 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.
540
541In either cases here are a few alternatives for the different syntaxes this syntax : \\
542\begin{center}
543{\renewcommand{\arraystretch}{1.5}
544\begin{tabular}[t]{l @{\hskip 0.35in} l}
545\hline
546\multicolumn{2}{ c }{\code{accept} on type}\\
547\hline
548Alternative 1 & Alternative 2 \\
549\begin{lstlisting}
550mutex struct A
551accept( void f(A & mutex a) )
552{};
553\end{lstlisting} &\begin{lstlisting}
554mutex struct A {}
555accept( void f(A & mutex a) );
556
557\end{lstlisting} \\
558Alternative 3 & Alternative 4 \\
559\begin{lstlisting}
560mutex struct A {
561        accept( void f(A & mutex a) )
562};
563
564\end{lstlisting} &\begin{lstlisting}
565mutex struct A {
566        accept :
567                void f(A & mutex a) );
568};
569\end{lstlisting}\\
570\hline
571\multicolumn{2}{ c }{\code{accept} on routine}\\
572\hline
573\begin{lstlisting}
574mutex struct A {};
575
576void f(A & mutex a)
577
578accept( void f(A & mutex a) )
579void g(A & mutex a) {
580        /*...*/
581}
582\end{lstlisting}&\\
583\end{tabular}
584}
585\end{center}
586
587An 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.
588
589\subsubsection{Multi-monitor scheduling}
590
591External 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 :
592\begin{lstlisting}
593        accept( void f(mutex struct A & mutex this))
594        mutex struct A {};
595
596        mutex struct B {};
597
598        void g(A & mutex a, B & mutex b) {
599                accept(f); //ambiguous, which monitor
600        }
601\end{lstlisting}
602
603The obvious solution is to specify the correct monitor as follows :
604
605\begin{lstlisting}
606        accept( void f(mutex struct A & mutex this))
607        mutex struct A {};
608
609        mutex struct B {};
610
611        void g(A & mutex a, B & mutex b) {
612                accept( f, b );
613        }
614\end{lstlisting}
615
616This 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.
617
618\begin{lstlisting}
619        accept( void f(mutex struct A & mutex, mutex struct A & mutex))
620        mutex struct A {};
621
622        mutex struct B {};
623
624        void g(A & mutex a, B & mutex b) {
625                accept( f, b, a );
626        }
627\end{lstlisting}
628
629Note 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.
630
631\subsubsection{Implementation Details: External scheduling queues}
632To 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.
633
634\subsection{Other concurrency tools}
635TO BE CONTINUED...
636
637\section{Parallelism}
638Historically, computer performance was about processor speeds and instructions count. However, with heat dissipaction being an ever growing challenge, parallelism has become the new source of greatest performance \cite{Sutter05, Sutter05b}. In this decade, it is not longer reasonnable create high-performance application without caring about parallelism. Indeed, parallelism an important aspect of performance and more specifically throughput and hardware utilization. The lowest level approach parallelism is to use \glspl{kthread}. 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 which all have strengths and weaknesses.
639
640\subsection{User-level threads}
641A 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 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 complexities are hidden, users still have to think about data races, deadlocks and synchronization issues. This can be somewhat alleviated by a concurrency toolkit with strong garantees but the parallelism toolkit offers very little to reduce complexity in itself.
642
643Examples of languages that support are Java\cite{Java}, Haskell\cite{Haskell} and \uC\cite{uC++book}.
644\subsection{Jobs and thread pools}
645The opposite approach is to base parallelism on \glspl{job}. Indeed, \glspl{job} offer limited flexibility but at the benefit of a simpler user interface. In \gls{job} based systems users express parallelism as units of work and the dependency graph (either explicit or implicit) that tie them together. This means users need not to worry about concurrency but significantly limits the interaction that can occur between different jobs. Indeed, any \gls{job} that blocks also blocks the underlying \gls{kthread}, this effectively mean the CPU utilization, and therefore throughput, will suffer noticeably. The golden standard of this implementation is Intel's TBB library\cite{TBB}.
646
647\subsection{Fibers : user-level threads without preemption}
648Finally, in the middle of the flexibility versus complexity spectrum lay \glspl{fiber} which offer \glspl{uthread} without the complexity of preemption. This means users don't have to worry about other \glspl{fiber} suddenly executing between two instructions which signficantly reduces complexity. However, any call to IO or other concurrency primitives can lead to context switches. Furthermore, users can also block \glspl{fiber} in the middle of their execution without blocking a full processor core. This means users still have to worry about mutual exclusion, deadlocks and race conditions in their code, raising the complexity significantly.
649\cite{Go}
650
651\subsection{Paradigm performance}
652While the choice between the three paradigms listed above may have significant performance implication, it is difficult to pin the performance implications of chosing a model at the language level. Indeed, in many situations own of these paradigms will show better performance but it all strongly depends on the usage. Having mostly indepent units of work to execute almost guarantess that the \gls{job} based system will have the best performance. However, add interactions between jobs and the processor utilisation might suffer. User-level threads may allow maximum ressource utilisation but context switches will be more expansive and it is also harder for users to get perfect tunning. As with every example, fibers sit somewhat in the middle of the spectrum. Furthermore, if the units of uninterrupted work are large enough the paradigm choice will be fully armoticised by the actual work done.
653
654\section{\CFA 's Thread Building Blocks}
655As 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, it is possible to deconstruct the three paradigms details aboved in order to get simple building blocks. Here is a table showing the core caracteristics of the mentionned paradigms :
656\begin{center}
657\begin{tabular}[t]{| r | c | c |}
658\cline{2-3}
659\multicolumn{1}{ c| }{} & Has a stack & Preemptive \\
660\hline
661\Glspl{job} & X & X \\
662\hline
663\Glspl{fiber} & \checkmark & X \\
664\hline
665\Glspl{uthread} & \checkmark & \checkmark \\
666\hline
667\end{tabular}
668\end{center}
669
670As shown in section \ref{cfaparadigms} these different blocks being available in \CFA it is trivial to reproduce any of these paradigm.
671
672\subsection{Thread Interface}
673The 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 comparatievely to \glspl{kthread}). A thread can be declared using a struct declaration prefix with the \code{thread} as follows :
674
675\begin{lstlisting}
676        thread struct foo {};
677\end{lstlisting}
678
679Obviously, for this thread implementation to be usefull it must run some user code. Several other threading interfaces use some function pointer representation as the interface of threads (for example : \Csharp \cite{Csharp} and Scala \cite{Scala}). However, we consider that statically tying a \code{main} routine to a thread superseeds this approach. Since the \code{main} routine is definetely a special routine in \CFA, we can reuse the existing syntax for declaring routines with unordinary name, i.e. operator overloading. As such the \code{main} routine of a thread can be defined as such :
680\begin{lstlisting}
681        thread struct foo {};
682
683        void ?main(thread foo* this) {
684                /*... Some useful code ...*/
685        }
686\end{lstlisting}
687
688With these semantics it is trivial to write a thread type that takes a function pointer as parameter and executes it on its stack asynchronously :
689\begin{lstlisting}
690        typedef void (*voidFunc)(void);
691
692        thread struct FuncRunner {
693                voidFunc func;
694        };
695
696        //ctor
697        void ?{}(thread FuncRunner* this, voidFunc inFunc) {
698                func = inFunc;
699        }
700
701        //main
702        void ?main(thread FuncRunner* this) {
703                this->func();
704        }
705\end{lstlisting}
706
707In this example \code{func} is a function pointer stored in \acrfull{tls}, which is \CFA is both easy to use and completly typesafe.
708
709Of course for threads to be useful, it must be possible to start and stop threads and wait for them to complete execution. While using \acrshort{api} such as \code{fork} and \code{join} is relatively common in the literature, such an interface is not needed. 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.
710\begin{lstlisting}
711thread struct FuncRunner; //FuncRunner declared above
712
713void world() {
714        sout | "World!" | endl;
715}
716
717void main() {
718        FuncRunner run = {world};
719        //Thread run forks here
720
721        //Print to "Hello " and "World!" will be run concurrently
722        sout | "Hello " | endl;
723
724        //Implicit join at end of scope
725}
726\end{lstlisting}
727This semantic has several advantages over explicit semantics : typesafety is guaranteed, any thread will always be started and stopped exaclty once and users can't make any progamming errors. Furthermore it naturally follows the memory allocation semantics which means users don't need to learn multiple semantics.
728
729These semantics also naturally scale to multiple threads meaning basic synchronisation is very simple :
730\begin{lstlisting}
731        thread struct MyThread {
732                //...
733        };
734
735        //ctor
736        void ?{}(thread MyThread* this) {}
737
738        //main
739        void ?main(thread MyThread* this) {
740                //...
741        }
742
743        void foo() {
744                MyThread thrds[10];
745                //Start 10 threads at the beginning of the scope
746
747                DoStuff();
748
749                //Wait for the 10 threads to finish
750        }
751\end{lstlisting}
752
753\subsection{The \CFA Kernel : Processors, Clusters and Threads}\label{kernel}
754
755
756\subsection{Paradigms}\label{cfaparadigms}
757Given 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.
758
759% \subsection{High-level options}\label{tasks}
760%
761% \subsubsection{Thread interface}
762% constructors destructors
763%       initializer lists
764% monitors
765%
766% \subsubsection{Futures}
767%
768% \subsubsection{Implicit threading}
769% 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.
770%
771% \begin{center}
772% \begin{tabular}[t]{|c|c|c|}
773% Sequential & System Parallel & Language Parallel \\
774% \begin{lstlisting}
775% void big_sum(int* a, int* b,
776%                int* out,
777%                size_t length)
778% {
779%       for(int i = 0; i < length; ++i ) {
780%               out[i] = a[i] + b[i];
781%       }
782% }
783%
784%
785%
786%
787%
788% int* a[10000];
789% int* b[10000];
790% int* c[10000];
791% //... fill in a and b ...
792% big_sum(a, b, c, 10000);
793% \end{lstlisting} &\begin{lstlisting}
794% void big_sum(int* a, int* b,
795%                int* out,
796%                size_t length)
797% {
798%       range ar(a, a + length);
799%       range br(b, b + length);
800%       range or(out, out + length);
801%       parfor( ai, bi, oi,
802%       [](int* ai, int* bi, int* oi) {
803%               oi = ai + bi;
804%       });
805% }
806%
807% int* a[10000];
808% int* b[10000];
809% int* c[10000];
810% //... fill in a and b ...
811% big_sum(a, b, c, 10000);
812% \end{lstlisting}&\begin{lstlisting}
813% void big_sum(int* a, int* b,
814%                int* out,
815%                size_t length)
816% {
817%       for (ai, bi, oi) in (a, b, out) {
818%               oi = ai + bi;
819%       }
820% }
821%
822%
823%
824%
825%
826% int* a[10000];
827% int* b[10000];
828% int* c[10000];
829% //... fill in a and b ...
830% big_sum(a, b, c, 10000);
831% \end{lstlisting}
832% \end{tabular}
833% \end{center}
834%
835% \subsection{Machine setup}\label{machine}
836% Threads are all good and well but wee still some OS support to fully utilize available hardware.
837%
838% \textbf{\large{Work in progress...}} Do wee need something beyond specifying the number of kernel threads?
839
840\section{Putting it all together}
841
842\section{Future work}
843Concurrency 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.
844\subsection{Transactions}
845
846\section*{Acknowledgements}
847
848\clearpage
849\printglossary[type=\acronymtype]
850\printglossary
851
852\clearpage
853\bibliographystyle{plain}
854\bibliography{pl,local}
855
856
857\end{document}
Note: See TracBrowser for help on using the repository browser.