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

aaron-thesisarm-ehcleanup-dtorsdeferred_resndemanglerenumforall-pointer-decayjacob/cs343-translationjenkins-sandboxnew-astnew-ast-unique-exprnew-envno_listpersistent-indexerpthread-emulationqualifiedEnumresolv-newwith_gc
Last change on this file since fe84230 was fe84230, checked in by Thierry Delisle <tdelisle@…>, 6 years ago
  • Added custom style file.
  • Updated text up-to internal scheduling
  • Property mode set to 100644
File size: 48.9 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 parallelism, 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. 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 will still have to take both paradigms into account. 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. 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 to 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 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. 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 their 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 large counter :
149
150\begin{lstlisting}
151        mutex struct counter_t { /*...*/ };
152
153        void ?{}(counter_t & nomutex this);
154        size_t ++?(counter_t & mutex this);
155
156        //need for mutex is platform dependent here
157        void ?{}(size_t * this, counter_t & mutex cnt);
158\end{lstlisting}
159*semantics of the declaration of \code{mutex struct counter_t} are discussed in details in section \ref{data}
160
161Here, 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 object not yet constructed should never be shared and therefore do 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.
162
163Having 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 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". 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.
164
165Regardless of which keyword is kept, it is important to establish when mutex/nomutex may be used as a type qualifier. Consider :
166\begin{lstlisting}
167        int f1(monitor & mutex m);
168        int f2(const monitor & mutex m);
169        int f3(monitor ** mutex m);
170        int f4(monitor *[] mutex m);
171        int f5(graph(monitor*) & mutex m);
172\end{lstlisting}
173
174The problem is to indentify which object(s) should be acquired. Furthermore, each object needs to be acquired 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 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} will be acquired, passing an array to this routine would be type safe and result in undefined behavior. For this reason, it would also be reasonnable to disallow mutex in the context where arrays may be passed.
175
176% ######     #    #######    #
177% #     #   # #      #      # #
178% #     #  #   #     #     #   #
179% #     # #     #    #    #     #
180% #     # #######    #    #######
181% #     # #     #    #    #     #
182% ######  #     #    #    #     #
183
184\subsubsection{Data semantics} \label{data}
185Once 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}:
186\begin{lstlisting}
187        mutex struct counter_t {
188                int value;
189        };
190
191        void ?{}(counter_t & nomutex this) {
192                this.cnt = 0;
193        }
194
195        int ++?(counter_t & mutex this) {
196                return ++this.value;
197        }
198
199        //need for mutex is platform dependent here
200        void ?{}(int * this, counter_t & mutex cnt) {
201                *this = (int)cnt;
202        }
203\end{lstlisting}
204
205This 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 :
206\begin{center}
207\begin{tabular}{c @{\hskip 0.35in} c @{\hskip 0.35in} c}
208\begin{lstlisting}
209        counter_t cnt;
210
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
220These simple mutual exclusion semantics also naturally expand 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}
228
229This code acquires both locks before entering the critical section (Referenced as \gls{group-acquire} from now on). In practice, writing multi-locking routines that can not lead to deadlocks can be 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 will be consistent across calls to routines using the same monitors as arguments. However, since \CFA monitors use multi-acquiring locks users can effectively force the acquiring order. For example, notice which routines use \code{mutex}/\code{nomutex} and how this affects aquiring order :
230\begin{lstlisting}
231        void foo(A & mutex a, B & mutex a) {
232                //...
233        }
234
235        void bar(A & mutex a, B & nomutex a)
236                //...
237                foo(a, b);
238                //...
239        }
240
241        void baz(A & nomutex a, B & mutex a)
242                //...
243                foo(a, b);
244                //...
245        }
246\end{lstlisting}
247
248Such a use will lead to nested monitor call problems~\cite{Lister77}, 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{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 deadlocks, depending on the implicit ordering matching the explicit ordering. As shown on several occasion\cit, solving this problems requires to :
249\begin{enumerate}
250        \item Dynamically track the monitor call order.
251        \item Implement rollback semantics.
252\end{enumerate}
253
254While 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.
255
256% ######  ####### #######    #    ### #        #####
257% #     # #          #      # #    #  #       #     #
258% #     # #          #     #   #   #  #       #
259% #     # #####      #    #     #  #  #        #####
260% #     # #          #    #######  #  #             #
261% #     # #          #    #     #  #  #       #     #
262% ######  #######    #    #     # ### #######  #####
263%
264%             ######  ####### #       #     # #     # ####### ######  #     #
265%             #     # #     # #        #   #  ##   ## #     # #     # #     #
266%             #     # #     # #         # #   # # # # #     # #     # #     #
267%  #####    ######  #     # #          #    #  #  # #     # ######  #######
268%             #       #     # #          #    #     # #     # #   #   #     #
269%             #       #     # #          #    #     # #     # #    #  #     #
270%             #       ####### #######    #    #     # ####### #     # #     #
271
272\subsubsection{Implementation Details: Interaction with polymorphism}
273At first glance, interaction between monitors and \CFA's concept of polymorphism seem complex to support. However, it can be reasoned that entry-point locking can solve most of the issues that could be present with polymorphism.
274
275First 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}\footnotemark 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}\footnotemark[\value{footnote}] calling a monitor routine becomes exactly the same as calling it from anywhere else.
276\footnotetext{See glossary for a definition of \gls{callsite-locking} and \gls{entry-point-locking}}
277
278% ### #     # #######         #####   #####  #     # ####### ######
279%  #  ##    #    #           #     # #     # #     # #       #     #
280%  #  # #   #    #           #       #       #     # #       #     #
281%  #  #  #  #    #            #####  #       ####### #####   #     #
282%  #  #   # #    #    ###          # #       #     # #       #     #
283%  #  #    ##    #    ###    #     # #     # #     # #       #     #
284% ### #     #    #    ###     #####   #####  #     # ####### ######
285
286\subsection{Internal scheduling} \label{insched}
287Monitors also need to schedule waiting threads within 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 have threads wait and signaled from them. Here is a simple example of such a technique :
288
289\begin{lstlisting}
290        mutex struct A {
291                condition e;
292        }
293
294        void foo(A & mutex a) {
295                //...
296                wait(a.e);
297                //...
298        }
299
300        void bar(A & mutex a) {
301                signal(a.e);
302        }
303\end{lstlisting}
304
305Here 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.
306\begin{center}
307\begin{tabular}{ c @{\hskip 0.65in} c }
308Thread 1 & Thread 2 \\
309\begin{lstlisting}
310void foo(monitor & mutex a,
311           monitor & mutex b) {
312        //...
313        wait(a.e);
314        //...
315}
316
317foo(a, b);
318\end{lstlisting} &\begin{lstlisting}
319void bar(monitor & mutex a,
320           monitor & mutex b) {
321        signal(a.e);
322}
323
324
325
326bar(a, b);
327\end{lstlisting}
328\end{tabular}
329\end{center}
330A 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):
331
332\begin{center}
333\begin{tabular}{|c|c|c|}
334Context 1 & Context 2 & Context 3 \\
335\hline
336\begin{lstlisting}
337condition e;
338
339void foo(monitor & mutex a,
340           monitor & mutex b) {
341
342        wait(e);
343}
344
345
346
347
348
349
350foo(a,b);
351\end{lstlisting} &\begin{lstlisting}
352condition e;
353
354void bar(monitor & mutex a,
355           monitor & nomutex b) {
356        foo(a,b);
357}
358
359void foo(monitor & mutex a,
360           monitor & mutex b) {
361        wait(e);
362}
363
364bar(a, b);
365\end{lstlisting} &\begin{lstlisting}
366condition e;
367
368void bar(monitor & mutex a,
369           monitor & nomutex b) {
370        baz(a,b);
371}
372
373void baz(monitor & nomutex a,
374           monitor & mutex b) {
375        wait(e);
376}
377
378bar(a, b);
379\end{lstlisting}
380\end{tabular}
381\end{center}
382
383Note that in \CFA, \code{condition} have no particular need to be stored inside a monitor, beyond any software engineering reasons. Context 1 is the simplest way of acquiring more than one monitor (\gls{group-acquire}), using a routine wiht 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 will 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.
384
385
386\begin{center}
387\begin{tabular}{|c|c|c|}
388\begin{lstlisting}
389condition e;
390
391//acquire a
392void foo(monitor & nomutex a,
393           monitor & mutex b) {
394        bar(a,b);
395}
396
397//acquire a
398void bar(monitor & mutex a,
399           monitor & nomutex b) {
400
401        //release a
402        //keep b
403        wait(e);
404}
405
406foo(a, b);
407\end{lstlisting} &\begin{lstlisting}
408condition e;
409
410//acquire a & b
411void foo(monitor & mutex a,
412           monitor & mutex b) {
413        bar(a,b);
414}
415
416//acquire b
417void bar(monitor & mutex a,
418           monitor & nomutex b) {
419
420        //release b
421        //keep a
422        wait(e);
423}
424
425foo(a, b);
426\end{lstlisting} &\begin{lstlisting}
427condition e;
428
429//acquire a & b
430void foo(monitor & mutex a,
431           monitor & mutex b) {
432        bar(a,b);
433}
434
435//acquire none
436void bar(monitor & nomutex a,
437           monitor & nomutex b) {
438
439        //release a & b
440        //keep none
441        wait(e);
442}
443
444foo(a, b);
445\end{lstlisting}
446\end{tabular}
447\end{center}
448Note the right-most example which uses a helper routine and therefore is not relevant to find which monitors will be released.
449
450These 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.
451
452Regardless of the context in which the \code{wait} statement is used, \code{signal} must used 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.
453
454Finally, 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.
455\\
456
457% ####### #     # #######         #####   #####  #     # ####### ######
458% #        #   #     #           #     # #     # #     # #       #     #
459% #         # #      #           #       #       #     # #       #     #
460% #####      #       #            #####  #       ####### #####   #     #
461% #         # #      #    ###          # #       #     # #       #     #
462% #        #   #     #    ###    #     # #     # #     # #       #     #
463% ####### #     #    #    ###     #####   #####  #     # ####### ######
464\newpage
465\subsection{External scheduling} \label{extsched}
466As 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.
467
468\begin{center}
469\begin{tabular}{|c|c|}
470Internal Scheduling & External Scheduling \\
471\hline
472\begin{lstlisting}
473        _Monitor blarg {
474                condition c;
475        public:
476                void f() { signal(c)}
477                void g() { wait(c); }
478        private:
479        }
480\end{lstlisting}&\begin{lstlisting}
481        _Monitor blarg {
482
483        public:
484                void f();
485                void g() { _Accept(f); }
486        private:
487        }
488\end{lstlisting}
489\end{tabular}
490\end{center}
491
492In 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.
493\\
494
495% #       ####### #######  #####  #######    ####### ######        #  #####
496% #       #     # #     # #     # #          #     # #     #       # #     #
497% #       #     # #     # #       #          #     # #     #       # #
498% #       #     # #     #  #####  #####      #     # ######        #  #####
499% #       #     # #     #       # #          #     # #     # #     #       #
500% #       #     # #     # #     # #          #     # #     # #     # #     #
501% ####### ####### #######  #####  #######    ####### ######   #####   #####
502
503\subsubsection{Loose object definitions}
504In \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 :
505
506\begin{lstlisting}
507        mutex struct A {};
508
509        void f(A & mutex a);
510        void g(A & mutex a) { accept(f); }
511\end{lstlisting}
512
513However, 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 :
514
515\begin{center}
516\begin{tabular}{l}
517\begin{lstlisting}[language=Pseudo]
518        if monitor is free :
519                enter
520        elif monitor accepts me :
521                enter
522        else :
523                block
524\end{lstlisting}
525\end{tabular}
526\end{center}
527
528For 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 :
529
530\begin{center}
531{\resizebox{0.4\textwidth}{!}{\input{monitor}}}
532\end{center}
533
534There 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.
535The alternative would be to have a picture more like this one:
536
537\begin{center}
538{\resizebox{0.4\textwidth}{!}{\input{ext_monitor}}}
539\end{center}
540
541Not 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.
542
543At 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.
544
545In either cases here are a few alternatives for the different syntaxes this syntax : \\
546\begin{center}
547{\renewcommand{\arraystretch}{1.5}
548\begin{tabular}[t]{l @{\hskip 0.35in} l}
549\hline
550\multicolumn{2}{ c }{\code{accept} on type}\\
551\hline
552Alternative 1 & Alternative 2 \\
553\begin{lstlisting}
554mutex struct A
555accept( void f(A & mutex a) )
556{};
557\end{lstlisting} &\begin{lstlisting}
558mutex struct A {}
559accept( void f(A & mutex a) );
560
561\end{lstlisting} \\
562Alternative 3 & Alternative 4 \\
563\begin{lstlisting}
564mutex struct A {
565        accept( void f(A & mutex a) )
566};
567
568\end{lstlisting} &\begin{lstlisting}
569mutex struct A {
570        accept :
571                void f(A & mutex a) );
572};
573\end{lstlisting}\\
574\hline
575\multicolumn{2}{ c }{\code{accept} on routine}\\
576\hline
577\begin{lstlisting}
578mutex struct A {};
579
580void f(A & mutex a)
581
582accept( void f(A & mutex a) )
583void g(A & mutex a) {
584        /*...*/
585}
586\end{lstlisting}&\\
587\end{tabular}
588}
589\end{center}
590
591An 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.
592
593% #     # #     # #       ####### ###    #     # ####### #     #
594% ##   ## #     # #          #     #     ##   ## #     # ##    #
595% # # # # #     # #          #     #     # # # # #     # # #   #
596% #  #  # #     # #          #     #     #  #  # #     # #  #  #
597% #     # #     # #          #     #     #     # #     # #   # #
598% #     # #     # #          #     #     #     # #     # #    ##
599% #     #  #####  #######    #    ###    #     # ####### #     #
600
601\subsubsection{Multi-monitor scheduling}
602
603External 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 :
604\begin{lstlisting}
605        accept( void f(mutex struct A & mutex this))
606        mutex struct A {};
607
608        mutex struct B {};
609
610        void g(A & mutex a, B & mutex b) {
611                accept(f); //ambiguous, which monitor
612        }
613\end{lstlisting}
614
615The obvious solution is to specify the correct monitor as follows :
616
617\begin{lstlisting}
618        accept( void f(mutex struct A & mutex this))
619        mutex struct A {};
620
621        mutex struct B {};
622
623        void g(A & mutex a, B & mutex b) {
624                accept( f, b );
625        }
626\end{lstlisting}
627
628This 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.
629
630\begin{lstlisting}
631        accept( void f(mutex struct A & mutex, mutex struct A & mutex))
632        mutex struct A {};
633
634        mutex struct B {};
635
636        void g(A & mutex a, B & mutex b) {
637                accept( f, b, a );
638        }
639\end{lstlisting}
640
641Note 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.
642
643% ######  ####### #######    #    ### #        #####
644% #     # #          #      # #    #  #       #     #
645% #     # #          #     #   #   #  #       #
646% #     # #####      #    #     #  #  #        #####
647% #     # #          #    #######  #  #             #
648% #     # #          #    #     #  #  #       #     #
649% ######  #######    #    #     # ### #######  #####
650%
651%                #####  #     # ####### #     # #######  #####
652%             #     # #     # #       #     # #       #     #
653%             #     # #     # #       #     # #       #
654%    #####    #     # #     # #####   #     # #####    #####
655%             #   # # #     # #       #     # #             #
656%             #    #  #     # #       #     # #       #     #
657%                #### #  #####  #######  #####  #######  #####
658
659
660\subsubsection{Implementation Details: External scheduling queues}
661To 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.
662
663\subsection{Other concurrency tools}
664TO BE CONTINUED...
665
666\newpage
667% ######     #    ######     #    #       #       ####### #       ###  #####  #     #
668% #     #   # #   #     #   # #   #       #       #       #        #  #     # ##   ##
669% #     #  #   #  #     #  #   #  #       #       #       #        #  #       # # # #
670% ######  #     # ######  #     # #       #       #####   #        #   #####  #  #  #
671% #       ####### #   #   ####### #       #       #       #        #        # #     #
672% #       #     # #    #  #     # #       #       #       #        #  #     # #     #
673% #       #     # #     # #     # ####### ####### ####### ####### ###  #####  #     #
674\section{Parallelism}
675Historically, computer performance was about processor speeds and instructions count. However, with heat dissipation 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 to create 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}. 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.
676
677\subsection{User-level threads}
678A 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.
679
680Examples of languages that support are Java~\cite{Java}, Haskell~\cite{Haskell} and \uC~\cite{uC++book}.
681
682\subsection{Jobs and thread pools}
683The approach on the opposite end of the spectrum 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.
684The golden standard of this implementation is Intel's TBB library~\cite{TBB}.
685
686\subsection{Fibers : user-level threads without preemption}
687Finally, 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.
688An example of a language that uses fibers is Go~\cite{Go}
689
690\subsection{Paradigm performance}
691While 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 one 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 largely amorticised by the actual work done.
692
693%  #####  #######    #          ####### ######  ######
694% #     # #         # #            #    #     # #     #
695% #       #        #   #           #    #     # #     #
696% #       #####   #     # #####    #    ######  ######
697% #       #       #######          #    #     # #     #
698% #     # #       #     #          #    #     # #     #
699%  #####  #       #     #          #    ######  ######
700
701\section{\CFA 's Thread Building Blocks}
702As 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 :
703\begin{center}
704\begin{tabular}[t]{| r | c | c |}
705\cline{2-3}
706\multicolumn{1}{ c| }{} & Has a stack & Preemptive \\
707\hline
708\Glspl{job} & X & X \\
709\hline
710\Glspl{fiber} & \checkmark & X \\
711\hline
712\Glspl{uthread} & \checkmark & \checkmark \\
713\hline
714\end{tabular}
715\end{center}
716
717As shown in section \ref{cfaparadigms} these different blocks being available in \CFA it is trivial to reproduce any of these paradigm.
718
719% ####### #     # ######  #######    #    ######   #####
720%    #    #     # #     # #         # #   #     # #     #
721%    #    #     # #     # #        #   #  #     # #
722%    #    ####### ######  #####   #     # #     #  #####
723%    #    #     # #   #   #       ####### #     #       #
724%    #    #     # #    #  #       #     # #     # #     #
725%    #    #     # #     # ####### #     # ######   #####
726
727\subsection{Thread Interface}
728The 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 :
729
730\begin{lstlisting}
731        thread struct foo {};
732\end{lstlisting}
733
734Obviously, 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 :
735\begin{lstlisting}
736        thread struct foo {};
737
738        void ?main(thread foo* this) {
739                /*... Some useful code ...*/
740        }
741\end{lstlisting}
742
743With these semantics it is trivial to write a thread type that takes a function pointer as parameter and executes it on its stack asynchronously :
744\begin{lstlisting}
745        typedef void (*voidFunc)(void);
746
747        thread struct FuncRunner {
748                voidFunc func;
749        };
750
751        //ctor
752        void ?{}(thread FuncRunner* this, voidFunc inFunc) {
753                func = inFunc;
754        }
755
756        //main
757        void ?main(thread FuncRunner* this) {
758                this->func();
759        }
760\end{lstlisting}
761
762% In this example \code{func} is a function pointer stored in \acrfull{tls}, which is \CFA is both easy to use and completly typesafe.
763
764Of 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 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.
765\begin{lstlisting}
766thread struct FuncRunner; //FuncRunner declared above
767
768void world() {
769        sout | "World!" | endl;
770}
771
772void main() {
773        FuncRunner run = {world};
774        //Thread run forks here
775
776        //Print to "Hello " and "World!" will be run concurrently
777        sout | "Hello " | endl;
778
779        //Implicit join at end of scope
780}
781\end{lstlisting}
782This 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.
783
784These semantics also naturally scale to multiple threads meaning basic synchronisation is very simple :
785\begin{lstlisting}
786        thread struct MyThread {
787                //...
788        };
789
790        //ctor
791        void ?{}(thread MyThread* this) {}
792
793        //main
794        void ?main(thread MyThread* this) {
795                //...
796        }
797
798        void foo() {
799                MyThread thrds[10];
800                //Start 10 threads at the beginning of the scope
801
802                DoStuff();
803
804                //Wait for the 10 threads to finish
805        }
806\end{lstlisting}
807
808\newpage
809\large{\textbf{WORK IN PROGRESS}}
810\subsection{The \CFA Kernel : Processors, Clusters and Threads}\label{kernel}
811
812
813\subsection{Paradigms}\label{cfaparadigms}
814Given 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.
815
816% \subsection{High-level options}\label{tasks}
817%
818% \subsubsection{Thread interface}
819% constructors destructors
820%       initializer lists
821% monitors
822%
823% \subsubsection{Futures}
824%
825% \subsubsection{Implicit threading}
826% 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.
827%
828% \begin{center}
829% \begin{tabular}[t]{|c|c|c|}
830% Sequential & System Parallel & Language Parallel \\
831% \begin{lstlisting}
832% void big_sum(int* a, int* b,
833%                int* out,
834%                size_t length)
835% {
836%       for(int i = 0; i < length; ++i ) {
837%               out[i] = a[i] + b[i];
838%       }
839% }
840%
841%
842%
843%
844%
845% int* a[10000];
846% int* b[10000];
847% int* c[10000];
848% //... fill in a and b ...
849% big_sum(a, b, c, 10000);
850% \end{lstlisting} &\begin{lstlisting}
851% void big_sum(int* a, int* b,
852%                int* out,
853%                size_t length)
854% {
855%       range ar(a, a + length);
856%       range br(b, b + length);
857%       range or(out, out + length);
858%       parfor( ai, bi, oi,
859%       [](int* ai, int* bi, int* oi) {
860%               oi = ai + bi;
861%       });
862% }
863%
864% int* a[10000];
865% int* b[10000];
866% int* c[10000];
867% //... fill in a and b ...
868% big_sum(a, b, c, 10000);
869% \end{lstlisting}&\begin{lstlisting}
870% void big_sum(int* a, int* b,
871%                int* out,
872%                size_t length)
873% {
874%       for (ai, bi, oi) in (a, b, out) {
875%               oi = ai + bi;
876%       }
877% }
878%
879%
880%
881%
882%
883% int* a[10000];
884% int* b[10000];
885% int* c[10000];
886% //... fill in a and b ...
887% big_sum(a, b, c, 10000);
888% \end{lstlisting}
889% \end{tabular}
890% \end{center}
891%
892% \subsection{Machine setup}\label{machine}
893% Threads are all good and well but wee still some OS support to fully utilize available hardware.
894%
895% \textbf{\large{Work in progress...}} Do wee need something beyond specifying the number of kernel threads?
896
897%    #    #       #
898%   # #   #       #
899%  #   #  #       #
900% #     # #       #
901% ####### #       #
902% #     # #       #
903% #     # ####### #######
904\section{Putting it all together}
905
906
907
908
909
910
911
912
913
914
915% ####### #     # ####### #     # ######  #######
916% #       #     #    #    #     # #     # #
917% #       #     #    #    #     # #     # #
918% #####   #     #    #    #     # ######  #####
919% #       #     #    #    #     # #   #   #
920% #       #     #    #    #     # #    #  #
921% #        #####     #     #####  #     # ######
922\section{Future work}
923Concurrency 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.
924\subsection{Transactions}
925
926% ####### #     # ######
927% #       ##    # #     #
928% #       # #   # #     #
929% #####   #  #  # #     #
930% #       #   # # #     #
931% #       #    ## #     #
932% ####### #     # ######
933\section*{Acknowledgements}
934
935\clearpage
936\printglossary[type=\acronymtype]
937\printglossary
938
939\clearpage
940\bibliographystyle{plain}
941\bibliography{cw92,distSharedMem,lfp92,mlw92,parallel,parallelIO,partheory,pl,pldi92,ps,realtime,techreportsPAB,visual,local}
942
943
944\end{document}
Note: See TracBrowser for help on using the repository browser.