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

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

-added pl blibliography
-rename citations to local bib
-added glossary
-started working on parallelism

  • Property mode set to 100644
File size: 35.7 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{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\renewcommand{\linenumberfont}{\scriptsize\sffamily}
36\input{common}                                          % bespoke macros used in the document
37\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
38\usepackage{breakurl}
39
40\renewcommand{\UrlFont}{\small\sf}
41
42\setlength{\topmargin}{-0.45in}                                                 % move running title into header
43\setlength{\headsep}{0.25in}
44
45%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
46
47% Names used in the document.
48
49\newcommand{\Version}{1.0.0}
50\newcommand{\CS}{C\raisebox{-0.9ex}{\large$^\sharp$}\xspace}
51
52\newcommand{\Textbf}[2][red]{{\color{#1}{\textbf{#2}}}}
53\newcommand{\Emph}[2][red]{{\color{#1}\textbf{\emph{#2}}}}
54\newcommand{\R}[1]{\Textbf{#1}}
55\newcommand{\B}[1]{{\Textbf[blue]{#1}}}
56\newcommand{\G}[1]{{\Textbf[OliveGreen]{#1}}}
57\newcommand{\uC}{$\mu$\CC}
58\newcommand{\cit}{\textsuperscript{[Citation Needed]}\xspace}
59\newcommand{\code}[1]{\lstinline{#1}}
60
61\input{glossary}
62
63\newsavebox{\LstBox}
64
65%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
66
67\setcounter{secnumdepth}{3}                             % number subsubsections
68\setcounter{tocdepth}{3}                                % subsubsections in table of contents
69\makeindex
70
71%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
72
73\begin{document}
74% \linenumbers
75
76\title{Concurrency in \CFA}
77\author{Thierry Delisle \\
78Dept. of Computer Science, University of Waterloo, \\ Waterloo, Ontario, Canada
79}
80
81\maketitle
82\section{Introduction}
83This 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 be to support higher level construct as the basis of the concurrency in \CFA.
84Indeed, for higly productive parallel programming high-level approaches are much more popular\cite{HPP:Study}. Examples are task based parallelism, message passing, implicit threading.
85
86There 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 ressource utilisation.
87
88\section{Concurrency}
89Several 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 completely (Erlang\cite{Erlang}, Haskell\cite{Haskell}, Akka (Scala)\cit). In the paradigms, interaction between 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. Which in turns mean that programmers need to learn two sets of designs patterns in order to be effective at their jobs. 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 paper proposes Monitors\cit as the core concurrency construct.
90
91Finally, 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.
92
93\section{Monitors}
94A 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 to be able to declare a handle to a shared object and a set of routines that act on it :
95\begin{lstlisting}
96        typedef /*some monitor type*/ monitor;
97        int f(monitor & m);
98
99        int main() {
100                monitor m;
101                f(m);
102        }
103\end{lstlisting}
104
105\subsection{Call semantics} \label{call}
106The 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 since at their core, monitors are simply implicit mutual exclusion objects (locks) and copying semantics of these is ill defined. Therefore, monitors are implicitly non-copyable.
107
108Another aspect to consider is when a monitor acquires its mutual exclusion. Indeed, a monitor may need to be passed to 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 :
109
110\begin{lstlisting}
111        mutex struct counter_t { /*...*/ };
112
113        void ?{}(counter_t & mutex this);
114        int ++?(counter_t & mutex this);
115        void ?{}(int * this, counter_t & mutex cnt);
116
117        bool is_zero(counter_t & nomutex this) {
118                int val = this;
119                return val == 0;
120        }
121\end{lstlisting}
122*semantics of the declaration of \code{mutex struct counter_t} will be discussed in details in \ref{data}
123
124This is an example of a monitor used as safe(ish) counter for concurrency. This API, which offers the prefix increment operator and a conversion operator to \code{int}, guarantees that reading the value (by converting it to \code{int}) and incrementing it are mutually exclusive. Note that the \code{is_zero} routine uses the \code{nomutex} keyword. Indeed, since reading the value is already atomic, there is no point in maintaining the mutual exclusion once the value is copied locally (in the variable \code{val} ).
125
126Having 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.
127
128Regardless of which keyword is kept, it is important to establish when mutex/nomutex may be used depending on type parameters.
129\begin{lstlisting}
130        int f01(monitor & mutex m);
131        int f02(const monitor & mutex m);
132        int f03(monitor * mutex m);
133        int f04(monitor * mutex * m);
134        int f05(monitor ** mutex m);
135        int f06(monitor[10] mutex m);
136        int f07(monitor[] mutex m);
137        int f08(vector(monitor) & mutex m);
138        int f09(list(monitor) & mutex m);
139        int f10([monitor*, int] & mutex m);
140        int f11(graph(monitor*) & mutex m);
141\end{lstlisting}
142
143For the first few routines it seems to make sense to support the mutex keyword for such small variations. The difference between pointers and reference (\code{f01} vs \code{f03}) or const and non-const (\code{f01} vs \code{f02}) has no significance to mutual exclusion. It may not always make sense to acquire the monitor when extra dereferences (\code{f04}, \code{f05}) are added but it is still technically feasible and the present of the explicit mutex keywork does make it very clear of the user's intentions. Passing in a known-sized array(\code{f06}) is also technically feasible but is close to the limits. Indeed, the size of the array is not actually enforced by the compiler and if replaced by a variable-sized array (\code{f07}) or a higher-level container (\code{f08}, \code{f09}) it becomes much more complex to properly acquire all the locks needed for such a complex critical section. This implicit acquisition also poses the question of what qualifies as a container. If the mutex keyword is supported on monitors stored inside of other types it can quickly become complex and unclear which monitor should be acquired and when. The extreme example of this is \code{f11} which takes a possibly cyclic graph of pointers to monitors. With such a routine signature the intuition of which monitors will be acquired on entry is lost\cite{Chicken}. Where to draw the lines is up for debate but it seems reasonnable to consider \code{f03} as accepted and \code{f06} as rejected.
144
145\subsection{Data semantics} \label{data}
146Once 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}:
147\begin{lstlisting}
148        mutex struct counter_t {
149                int value;
150        };
151
152        void ?{}(counter_t & mutex this) {
153                this.cnt = 0;
154        }
155
156        int ++?(counter_t & mutex this) {
157                return ++this->value;
158        }
159
160        void ?{}(int * this, counter_t & mutex cnt) {
161                *this = (int)cnt;
162        }
163\end{lstlisting}
164\begin{tabular}{ c c }
165Thread 1 & Thread 2 \\
166\begin{lstlisting}
167        void main(counter_t & mutex c) {
168                for(;;) {
169                        int count = c;
170                        sout | count | endl;
171                }
172        }
173\end{lstlisting} &\begin{lstlisting}
174        void main(counter_t & mutex c) {
175                for(;;) {
176                        ++c;
177                }
178        }
179
180\end{lstlisting}
181\end{tabular}
182\\
183
184
185This 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. \\
186
187These simple mutual exclusion semantics also naturally expand to multi-monitor calls.
188\begin{lstlisting}
189        int f(MonitorA & mutex a, MonitorB & mutex b);
190
191        MonitorA a;
192        MonitorB b;
193        f(a,b);
194\end{lstlisting}
195
196This code acquires both locks before entering the critical section. In practice, writing multi-locking routines that can lead to deadlocks can be very tricky. Having language level support for such feature is therefore a significant asset for \CFA. However, as the this proposal shows, this does have significant repercussions relating to scheduling (see \ref{insched} and \ref{extsched}). The ability to acquire multiple monitors at the same time does incur a significant pitfall even without looking into scheduling. For example :
197\begin{lstlisting}
198        void foo(A & mutex a, B & mutex a) {
199                //...
200        }
201
202        void bar(A & mutex a, B & nomutex a)
203                //...
204                foo(a, b);
205                //...
206        }
207
208        void baz(A & nomutex a, B & mutex a)
209                //...
210                foo(a, b);
211                //...
212        }
213\end{lstlisting}
214
215TODO: dig further into monitor order aquiring
216
217Thoughs : calls to \code{baz} and \code{bar} are definitely incompatible because they explicitly acquire locks in reverse order and therefore are explicitly asking for a deadlock. The best that can be done in this situatuin is to detect the deadlock. The case of implicit ordering is less clear because in the case of monitors the runtime system \textit{may} be smart enough to figure out that someone is waiting with explicit ordering... maybe.
218
219\subsubsection{Internal scheduling} \label{insched}
220Monitors 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 :
221
222\begin{lstlisting}
223        mutex struct A {
224                condition e;
225        }
226
227        void foo(A & mutex a) {
228                //...
229                wait(a.e);
230                //...
231        }
232
233        void bar(A & mutex a) {
234                signal(a.e);
235        }
236\end{lstlisting}
237
238Here routine \code{foo} waits on the \code{signal} from \code{bar} before making further progress, effectively ensuring a basic ordering. This can easily be extended to multi-monitor calls by offering the same guarantee.
239
240\begin{center}
241\begin{tabular}{ c @{\hskip 0.65in} c }
242Thread 1 & Thread 2 \\
243\begin{lstlisting}
244void foo(monitor & mutex a,
245         monitor & mutex b) {
246        //...
247        wait(a.e);
248        //...
249}
250
251foo(a, b);
252\end{lstlisting} &\begin{lstlisting}
253void bar(monitor & mutex a,
254         monitor & mutex b) {
255        signal(a.e);
256}
257
258
259
260bar(a, b);
261\end{lstlisting}
262\end{tabular}
263\end{center}
264
265A 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 :
266
267\begin{center}
268\begin{tabular}{|c|c|c|}
269Context 1 & Context 2 & Context 3 \\
270\hline
271\begin{lstlisting}
272void foo(monitor & mutex a,
273         monitor & mutex b) {
274        wait(a.e);
275}
276
277
278
279
280
281
282foo(a,b);
283\end{lstlisting} &\begin{lstlisting}
284void bar(monitor & mutex a,
285         monitor & nomutex b) {
286        foo(a,b);
287}
288
289void foo(monitor & mutex a,
290         monitor & mutex b) {
291        wait(a.e);
292}
293
294bar(a, b);
295\end{lstlisting} &\begin{lstlisting}
296void bar(monitor & mutex a,
297         monitor & nomutex b) {
298        foo(a,b);
299}
300
301void baz(monitor & nomutex a,
302         monitor & mutex b) {
303        wait(a.e);
304}
305
306bar(a, b);
307\end{lstlisting}
308\end{tabular}
309\end{center}
310
311This can be interpreted in two different ways :
312\begin{enumerate}
313        \item \code{wait} atomically releases the monitors \underline{theoretically} acquired by the inner-most mutex routine.
314        \item \code{wait} atomically releases the monitors \underline{actually} acquired by the inner-most mutex routine.
315\end{enumerate}
316While 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.
317
318\begin{center}
319\begin{tabular}{c @{\hskip 0.35in} c @{\hskip 0.35in} c}
320\begin{lstlisting}
321enterMonitor(a);
322enterMonitor(b);
323// do stuff
324leaveMonitor(b);
325leaveMonitor(a);
326\end{lstlisting} & != &\begin{lstlisting}
327enterMonitor(a);
328enterMonitor(a, b);
329// do stuff
330leaveMonitor(a, b);
331leaveMonitor(a);
332\end{lstlisting}
333\end{tabular}
334\end{center}
335
336This is not intuitive because even if both methods will 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 \underline{actually} acquired monitors. 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} will actually behave 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.
337\\
338
339The following examples shows three alternatives of explicit wait semantics :
340\\
341
342\begin{center}
343\begin{tabular}{|c|c|c|}
344Case 1 & Case 2 & Case 3 \\
345Branding on construction & Explicit release list & Explicit ignore list \\
346\hline
347\begin{lstlisting}
348void foo(monitor & mutex a,
349         monitor & mutex b,
350           condition & c)
351{
352        // Releases monitors
353        // branded in ctor
354        wait(c);
355}
356
357monitor a;
358monitor b;
359condition1 c1 = {a};
360condition2 c2 = {a, b};
361
362//Will release only a
363foo(a,b,c1);
364
365//Will release a and b
366foo(a,b,c2);
367\end{lstlisting} &\begin{lstlisting}
368void foo(monitor & mutex a,
369         monitor & mutex b,
370           condition & c)
371{
372        // Releases monitor a
373        // Holds monitor b
374        waitRelease(c, [a]);
375}
376
377monitor a;
378monitor b;
379condition c;
380
381
382
383foo(a,b,c);
384
385
386
387\end{lstlisting} &\begin{lstlisting}
388void foo(monitor & mutex a,
389         monitor & mutex b,
390           condition & c)
391{
392        // Releases monitor a
393        // Holds monitor b
394        waitHold(c, [b]);
395}
396
397monitor a;
398monitor b;
399condition c;
400
401
402
403foo(a,b,c);
404
405
406
407\end{lstlisting}
408\end{tabular}
409\end{center}
410(Note : Case 2 and 3 use tuple semantics to pass a variable length list of elements.)
411\\
412
413All these cases have there pros and cons. Case 1 is more distinct because it means programmers need to be carefull about where the condition was initialized as well as where it is used. On the other hand, it is very clear and explicit which monitor will be released and which monitor will stay 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 will release 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 :
414\begin{lstlisting}
415void wait(condition & cond) {
416        waitHold(cond, []);
417}
418\end{lstlisting}
419This 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 :
420\begin{lstlisting}
421extern void doStuff();
422
423void foo(monitor & mutex m) {
424        //...
425        doStuff(); //warning can release monitor m
426        //...
427}
428\end{lstlisting}
429
430Indeed, if Case 2 or 3 are chosen it any code can violate the mutual exclusion of 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 syntaxes proposed in case 1 and 2 are not exclusive. Indeed, by supporting two types of condition as follows both cases can be supported :
431\begin{lstlisting}
432struct condition { /*...*/ };
433
434// Second argument is a variable length tuple.
435void wait(condition & cond, [...] monitorsToRelease);
436void signal(condition & cond);
437
438struct conditionN { /*...*/ };
439
440void ?{}(conditionN* this, /*list of N monitors to release*/);
441void wait(conditionN & cond);
442void signal(conditionN & cond);
443\end{lstlisting}
444
445Regardless 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) than the call to \code{wait}. Otherwise, mutual exclusion cannot be properly transferred back to the waiting monitor.
446
447Finally, 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.
448
449\subsection{External scheduling} \label{extsched}
450As 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 demontrate, 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 (see \uC) or in terms of data (see 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 reset of the languages semantics. Two challenges specific to \CFA arise when trying to add external scheduling which is 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.
451
452\begin{center}
453\begin{tabular}{|c|c|}
454Internal Scheduling & External Scheduling \\
455\hline
456\begin{lstlisting}
457        _Monitor blarg {
458                condition c;
459        public:
460                void f();
461                void g() { signal}
462                void h() { wait(c); }
463        private:
464        }
465\end{lstlisting}&\begin{lstlisting}
466        _Monitor blarg {
467
468        public:
469                void f();
470                void g();
471                void h() { _Accept(g); }
472        private:
473        }
474\end{lstlisting}
475\end{tabular}
476\end{center}
477
478In 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.
479
480\subsubsection{Loose object definitions}
481In \uC monitor definitions include an exhaustive list of monitor operations. Since \CFA is not an object oriented it becomes much more difficult to implement but also much less clear for the user :
482
483\begin{lstlisting}
484        mutex struct A {};
485
486        void f(A & mutex a);
487        void g(A & mutex a);
488        void h(A & mutex a) { accept(g); }
489\end{lstlisting}
490
491While this is the direct translation of the \uC code, at the time of compiling routine \code{f} the \CFA does not already have a declaration of \code{g} while the \uC compiler does. This means that either the compiler has to dynamically find which routines are "acceptable" or the language needs a way of statically listing "acceptable" routines. Since \CFA has no existing concept that resemble dynamic routine definitions or pattern matching, the static approach seems the more consistent with the current language paradigms. This approach leads to the \uC example being translated to :
492\begin{lstlisting}
493        accept( void g(mutex struct A & mutex a) )
494        mutex struct A {};
495
496        void f(A & mutex a) { accept(g); }
497        void g(A & mutex a);
498\end{lstlisting}
499
500This syntax is the most consistent with the language since it somewhat mimics the \code{forall} declarations. However, the fact that it comes before the struct declaration does means the type needs to be forward declared (done inline in the example). Here are a few alternatives to this syntax : \\
501\begin{tabular}[t]{l l}
502Alternative 1 & Alternative 2 \\
503\begin{lstlisting}
504mutex struct A
505accept( void g(A & mutex a) )
506{};
507\end{lstlisting} &\begin{lstlisting}
508mutex struct A {}
509accept( void g(A & mutex a) );
510
511\end{lstlisting} \\
512Alternative 3 & Alternative 4 \\
513\begin{lstlisting}
514mutex struct A {
515        accept( void g(A & mutex a) )
516};
517
518\end{lstlisting} &\begin{lstlisting}
519mutex struct A {
520        accept :
521                void g(A & mutex a) );
522};
523\end{lstlisting}
524\end{tabular}
525
526
527An 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.
528
529\subsubsection{Multi-monitor scheduling}
530
531External 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 :
532\begin{lstlisting}
533        accept( void f(mutex struct A & mutex this))
534        mutex struct A {};
535
536        mutex struct B {};
537
538        void g(A & mutex a, B & mutex b) {
539                accept(f); //ambiguous, which monitor
540        }
541\end{lstlisting}
542
543The obvious solution is to specify the correct monitor as follows :
544
545\begin{lstlisting}
546        accept( void f(mutex struct A & mutex this))
547        mutex struct A {};
548
549        mutex struct B {};
550
551        void g(A & mutex a, B & mutex b) {
552                accept( f, b );
553        }
554\end{lstlisting}
555
556This is unambiguous. The 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.
557
558\begin{lstlisting}
559        accept( void f(mutex struct A & mutex, mutex struct A & mutex))
560        mutex struct A {};
561
562        mutex struct B {};
563
564        void g(A & mutex a, B & mutex b) {
565                accept( f, b, a );
566        }
567\end{lstlisting}
568
569Note 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.
570
571\subsection{Implementation Details}
572\textbf{\large{Work in progress...}}
573\subsubsection{Interaction with polymorphism}
574At 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.
575
576First 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.
577
578\subsubsection{External scheduling queues}
579To 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 most 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 gut that is a reasonnable contraint. This algorithm choice has two consequences, the ofthe 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 probably that half the multi-monitor queues will go unused for the entire duration of the program.
580
581\subsection{Other concurrency tools}
582
583\section{Parallelism}
584Historically, 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.
585
586\subsection{User-level threads}
587A 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.
588
589Examples of languages that support are Java\cite{Java}, Haskell\cite{Haskell} and \uC\cite{uC++book}.
590
591\subsection{Jobs and thread pools}
592The 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}.
593
594\subsection{Fibers : user-level threads without preemption}
595Finally, 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.
596\cite{Go}
597
598\subsection{Paradigm performance}
599While the choice between the three paradigms listed above can 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 depends on the usage.
600Having 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.
601
602\section{Parallelism in \CFA}
603As 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.
604
605\subsection{Kernel core}\label{kernel}
606At the ro
607\subsubsection{Threads}
608\CFA threads have all the caracteristiques of
609
610\subsection{High-level options}\label{tasks}
611
612\subsubsection{Thread interface}
613constructors destructors
614        initializer lists
615monitors
616
617\subsubsection{Futures}
618
619\subsubsection{Implicit threading}
620Finally, 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.
621
622\begin{center}
623\begin{tabular}[t]{|c|c|c|}
624Sequential & System Parallel & Language Parallel \\
625\begin{lstlisting}
626void big_sum(int* a, int* b,
627                 int* out,
628                 size_t length)
629{
630        for(int i = 0; i < length; ++i ) {
631                out[i] = a[i] + b[i];
632        }
633}
634
635
636
637
638
639int* a[10000];
640int* b[10000];
641int* c[10000];
642//... fill in a and b ...
643big_sum(a, b, c, 10000);
644\end{lstlisting} &\begin{lstlisting}
645void big_sum(int* a, int* b,
646                 int* out,
647                 size_t length)
648{
649        range ar(a, a + length);
650        range br(b, b + length);
651        range or(out, out + length);
652        parfor( ai, bi, oi,
653        [](int* ai, int* bi, int* oi) {
654                oi = ai + bi;
655        });
656}
657
658int* a[10000];
659int* b[10000];
660int* c[10000];
661//... fill in a and b ...
662big_sum(a, b, c, 10000);
663\end{lstlisting}&\begin{lstlisting}
664void big_sum(int* a, int* b,
665                 int* out,
666                 size_t length)
667{
668        for (ai, bi, oi) in (a, b, out) {
669                oi = ai + bi;
670        }
671}
672
673
674
675
676
677int* a[10000];
678int* b[10000];
679int* c[10000];
680//... fill in a and b ...
681big_sum(a, b, c, 10000);
682\end{lstlisting}
683\end{tabular}
684\end{center}
685
686\subsection{Machine setup}\label{machine}
687Threads are all good and well but wee still some OS support to fully utilize available hardware.
688
689\textbf{\large{Work in progress...}} Do wee need something beyond specifying the number of kernel threads?
690
691\section{Future work}
692Concurrency 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.
693\subsection{Transactions}
694
695\section*{Acknowledgements}
696
697\clearpage
698\printglossary
699
700\clearpage
701\bibliographystyle{plain}
702\bibliography{pl,local}
703
704
705\end{document}
Note: See TracBrowser for help on using the repository browser.