source: doc/proposals/concurrency/text/basics.tex @ 21a1efb

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

Sent a draft to peter

  • Property mode set to 100644
File size: 16.5 KB
Line 
1% ======================================================================
2% ======================================================================
3\chapter{Basics}\label{basics}
4% ======================================================================
5% ======================================================================
6Before any detailed discussion of the concurrency and parallelism in \CFA, it is important to describe the basics of concurrency and how they are expressed in \CFA user code.
7
8\section{Basics of concurrency}
9At its core, concurrency is based on having call-stacks and potentially multiple threads of execution for these stacks. Concurrency without parallelism only requires having multiple call stacks (or contexts) for a single thread of execution, and switching between these call stacks on a regular basis. A minimal concurrency product can be achieved by creating coroutines, which instead of context switching between each other, always ask an oracle where to context switch next. While coroutines do not technically require a stack, stackfull coroutines are the closest abstraction to a practical "naked"" call stack. When writing concurrency in terms of coroutines, the oracle effectively becomes a scheduler and the whole system now follows a cooperative threading-model \cit. The oracle/scheduler can either be a stackless or stackfull entity and correspondingly require one or two context switches to run a different coroutine. In any case, a subset of concurrency related challenges start to appear. For the complete set of concurrency challenges to occur, the only feature missing is preemption. Indeed, concurrency challenges appear with non-determinism. Guaranteeing mutual-exclusion or synchronisation are simply ways of limiting the lack of determinism in a system. A scheduler introduces order of execution uncertainty, while preemption introduces incertainty about where context-switches occur. Now it is important to understand that uncertainty is not necessarily undesireable; uncertainty can often be used by systems to significantly increase performance and is often the basis of giving a user the illusion that tasks are running in parallel. Optimal performance in concurrent applications is often obtained by having as much non-determinism as correctness allows\cit.
10
11\section{\protect\CFA 's Thread Building Blocks}
12One of the important features that is missing in C is threading. On modern architectures, a lack of threading is becoming less and less forgivable\cite{Sutter05, Sutter05b}, and therefore modern programming languages must have the proper tools to allow users to write performant concurrent and/or parallel programs. As an extension of C, \CFA needs to express these concepts in a way that is as natural as possible to programmers used to imperative languages. And being a system-level language means programmers expect to choose precisely which features they need and which cost they are willing to pay.
13
14\section{Coroutines: A stepping stone}\label{coroutine}
15While the main focus of this proposal is concurrency and parallelism, as mentionned above it is important to adress coroutines, which are actually a significant underlying aspect of a concurrency system. Indeed, while having nothing to do with parallelism and arguably little to do with concurrency, coroutines need to deal with context-switchs and other context-management operations. Therefore, this proposal includes coroutines both as an intermediate step for the implementation of threads, and a first class feature of \CFA. Furthermore, many design challenges of threads are at least partially present in designing coroutines, which makes the design effort that much more relevant. The core API of coroutines revolve around two features: independent call stacks and \code{suspend}/\code{resume}.
16
17Here is an example of a solution to the fibonnaci problem using \CFA coroutines:
18\begin{cfacode}
19        coroutine Fibonacci {
20              int fn; // used for communication
21        };
22
23        void ?{}(Fibonacci & this) { // constructor
24              this.fn = 0;
25        }
26
27        // main automacically called on first resume
28        void main(Fibonacci & this) {
29                int fn1, fn2;           // retained between resumes
30                this.fn = 0;
31                fn1 = this.fn;
32                suspend(this);          // return to last resume
33
34                this.fn = 1;
35                fn2 = fn1;
36                fn1 = this.fn;
37                suspend(this);          // return to last resume
38
39                for ( ;; ) {
40                        this.fn = fn1 + fn2;
41                        fn2 = fn1;
42                        fn1 = this.fn;
43                        suspend(this);  // return to last resume
44                }
45        }
46
47        int next(Fibonacci & this) {
48                resume(this); // transfer to last suspend
49                return this.fn;
50        }
51
52        void main() { // regular program main
53                Fibonacci f1, f2;
54                for ( int i = 1; i <= 10; i += 1 ) {
55                        sout | next( f1 ) | next( f2 ) | endl;
56                }
57        }
58\end{cfacode}
59
60\subsection{Construction}
61One important design challenge for coroutines and threads (shown in section \ref{threads}) is that the runtime system needs to run code after the user-constructor runs. In the case of coroutines, this challenge is simpler since there is no non-determinism from preemption or scheduling. However, the underlying challenge remains the same for coroutines and threads.
62
63The runtime system needs to create the coroutine's stack and more importantly prepare it for the first resumption. The timing of the creation is non-trivial since users both expect to have fully constructed objects once execution enters the coroutine main and to be able to resume the coroutine from the constructor. Like for regular objects, constructors can still leak coroutines before they are ready. There are several solutions to this problem but the chosen options effectively forces the design of the coroutine.
64
65Furthermore, \CFA faces an extra challenge as polymorphic routines create invisible thunks when casted to non-polymorphic routines and these thunks have function scope. For example, the following code, while looking benign, can run into undefined behaviour because of thunks:
66
67\begin{cfacode}
68//async: Runs function asynchronously on another thread
69forall(otype T)
70extern void async(void (*func)(T*), T* obj);
71
72forall(otype T)
73void noop(T *) {}
74
75void bar() {
76        int a;
77        async(noop, &a);
78}
79\end{cfacode}
80The generated C code\footnote{Code trimmed down for brevity} creates a local thunk to hold type information:
81
82\begin{ccode}
83extern void async(/* omitted */, void (*func)(void *), void *obj);
84
85void noop(/* omitted */, void *obj){}
86
87void bar(){
88        int a;
89        void _thunk0(int *_p0){
90                /* omitted */
91                noop(/* omitted */, _p0);
92        }
93        /* omitted */
94        async(/* omitted */, ((void (*)(void *))(&_thunk0)), (&a));
95}
96\end{ccode}
97The problem in this example is a race condition between the start of the execution of \code{noop} on the other thread and the stack frame of \code{bar} being destroyed. This extra challenge limits which solutions are viable because storing the function pointer for too long only increases the chances that the race will end in undefined behavior; i.e. the stack based thunk being destroyed before it was used. This challenge is an extension of challenges that come with second-class routines. Indeed, GCC nested routines also have the limitation that the routines cannot be passed outside of the scope of the functions these were declared in. The case of coroutines and threads is simply an extension of this problem to multiple call-stacks.
98
99\subsection{Alternative: Composition}
100One solution to this challenge would be to use composition/containement,
101
102\begin{cfacode}
103        struct Fibonacci {
104              int fn; // used for communication
105              coroutine c; //composition
106        };
107
108        void ?{}(Fibonacci & this) {
109              this.fn = 0;
110                (this.c){};
111        }
112\end{cfacode}
113There are two downsides to this approach. The first, which is relatively minor, is that the base class needs to be made aware of the main routine pointer, regardless of whether a parameter or a virtual pointer is used, this means the coroutine data must be made larger to store a value that is actually a compile time constant (address of the main routine). The second problem, which is both subtle and significant, is that now users can get the initialisation order of there coroutines wrong. Indeed, every field of a \CFA struct is constructed but in declaration order, unless users explicitly write otherwise. This semantics means that users who forget to initialize a the coroutine may resume the coroutine with an uninitilized object. For coroutines, this is unlikely to be a problem, for threads however, this is a significant problem.
114
115\subsection{Alternative: Reserved keyword}
116The next alternative is to use language support to annotate coroutines as follows:
117
118\begin{cfacode}
119        coroutine Fibonacci {
120              int fn; // used for communication
121        };
122\end{cfacode}
123This mean the compiler can solve problems by injecting code where needed. The downside of this approach is that it makes coroutine a special case in the language. Users who would want to extend coroutines or build their own for various reasons can only do so in ways offered by the language. Furthermore, implementing coroutines without language supports also displays the power of \CFA.
124While this is ultimately the option used for idiomatic \CFA code, coroutines and threads can both be constructed by users without using the language support. The reserved keywords are only present to improve ease of use for the common cases.
125
126\subsection{Alternative: Lamda Objects}
127
128For coroutines as for threads, many implementations are based on routine pointers or function objects\cit. For example, Boost implements coroutines in terms of four functor object types:
129\begin{cfacode}
130asymmetric_coroutine<>::pull_type
131asymmetric_coroutine<>::push_type
132symmetric_coroutine<>::call_type
133symmetric_coroutine<>::yield_type
134\end{cfacode}
135Often, the canonical threading paradigm in languages is based on function pointers, pthread being one of the most well known examples. The main problem of this approach is that the thread usage is limited to a generic handle that must otherwise be wrapped in a custom type. Since the custom type is simple to write in \CFA and solves several issues, added support for routine/lambda based coroutines adds very little.
136
137A variation of this would be to use an simple function pointer in the same way pthread does for threads :
138\begin{cfacode}
139void foo( coroutine_t cid, void * arg ) {
140        int * value = (int *)arg;
141        //Coroutine body
142}
143
144int main() {
145        int value = 0;
146        coroutine_t cid = coroutine_create( &foo, (void*)&value );
147        coroutine_resume( &cid );
148}
149\end{cfacode}
150This semantic is more common for thread interfaces than coroutines but would work equally well. As discussed in section \ref{threads}, this approach is superseeded by static approaches in terms of expressivity.
151
152\subsection{Alternative: Trait-based coroutines}
153
154Finally the underlying approach, which is the one closest to \CFA idioms, is to use trait-based lazy coroutines. This approach defines a coroutine as anything that satisfies the trait \code{is_coroutine} and is used as a coroutine.
155
156\begin{cfacode}
157trait is_coroutine(dtype T) {
158      void main(T & this);
159      coroutine_desc * get_coroutine(T & this);
160};
161\end{cfacode}
162This ensures an object is not a coroutine until \code{resume} (or \code{prime}) is called on the object. Correspondingly, any object that is passed to \code{resume} is a coroutine since it must satisfy the \code{is_coroutine} trait to compile. The advantage of this approach is that users can easily create different types of coroutines, for example, changing the memory foot print of a coroutine is trivial when implementing the \code{get_coroutine} routine. The \CFA keyword \code{coroutine} only has the effect of implementing the getter and forward declarations required for users to only have to implement the main routine.
163
164\begin{center}
165\begin{tabular}{c c c}
166\begin{cfacode}[tabsize=3]
167coroutine MyCoroutine {
168        int someValue;
169};
170\end{cfacode} & == & \begin{cfacode}[tabsize=3]
171struct MyCoroutine {
172        int someValue;
173        coroutine_desc __cor;
174};
175
176static inline
177coroutine_desc * get_coroutine(
178        struct MyCoroutine & this
179) {
180        return &this.__cor;
181}
182
183void main(struct MyCoroutine * this);
184\end{cfacode}
185\end{tabular}
186\end{center}
187
188The combination of these two approaches allows users new to concurrency to have a easy and concise method while more advanced users can expose themselves to otherwise hidden pitfalls at the benefit of tighter control on memory layout and initialization.
189
190\section{Thread Interface}\label{threads}
191The basic building blocks of multi-threading in \CFA are \glspl{cfathread}. Both user and kernel threads are supported, where user threads are the concurrency mechanism and kernel threads are the parallel mechanism. User threads offer a flexible and lightweight interface. A thread can be declared using a struct declaration \code{thread} as follows:
192
193\begin{cfacode}
194        thread foo {};
195\end{cfacode}
196
197As for coroutines, the keyword is a thin wrapper arount a \CFA trait:
198
199\begin{cfacode}
200trait is_thread(dtype T) {
201      void ^?{}(T & mutex this);
202      void main(T & this);
203      thread_desc* get_thread(T & this);
204};
205\end{cfacode}
206
207Obviously, for this thread implementation to be usefull it must run some user code. Several other threading interfaces use a function-pointer representation as the interface of threads (for example \Csharp~\cite{Csharp} and Scala~\cite{Scala}). However, this proposal considers that statically tying a \code{main} routine to a thread superseeds this approach. Since the \code{main} routine is already a special routine in \CFA (where the program begins), it is possible naturally extend the semantics using overloading to declare mains for different threads (the normal main being the main of the initial thread). As such the \code{main} routine of a thread can be defined as
208\begin{cfacode}
209        thread foo {};
210
211        void main(foo & this) {
212                sout | "Hello World!" | endl;
213        }
214\end{cfacode}
215
216In this example, threads of type \code{foo} start execution in the \code{void main(foo*)} routine which prints \code{"Hello World!"}. While this proposoal encourages this approach to enforce strongly-typed programming, users may prefer to use the routine based thread semantics for the sake of simplicity. With these semantics it is trivial to write a thread type that takes a function pointer as parameter and executes it on its stack asynchronously
217\begin{cfacode}
218        typedef void (*voidFunc)(void);
219
220        thread FuncRunner {
221                voidFunc func;
222        };
223
224        //ctor
225        void ?{}(FuncRunner & this, voidFunc inFunc) {
226                this.func = inFunc;
227        }
228
229        //main
230        void main(FuncRunner & this) {
231                this.func();
232        }
233\end{cfacode}
234
235An advantage of the overloading approach to main is to clearly highlight where and what memory is required to pass parameters and return values to/from a thread.
236
237Of course for threads to be useful, it must be possible to start and stop threads and wait for them to complete execution. While using an \acrshort{api} such as \code{fork} and \code{join} is relatively common in the literature, such an interface is unnecessary. Indeed, the simplest approach is to use \acrshort{raii} principles and have threads \code{fork} once the constructor has completed and \code{join} before the destructor runs.
238\begin{cfacode}
239thread World;
240
241void main(World & this) {
242        sout | "World!" | endl;
243}
244
245void main() {
246        World w;
247        //Thread forks here
248
249        //Printing "Hello " and "World!" are run concurrently
250        sout | "Hello " | endl;
251
252        //Implicit join at end of scope
253}
254\end{cfacode}
255
256This semantic has several advantages over explicit semantics typesafety is guaranteed, a thread is always started and stopped exaclty once and users cannot make any progamming errors. Another advantage of this semantic is that it naturally scale to multiple threads meaning basic synchronisation is very simple
257
258\begin{cfacode}
259thread MyThread {
260        //...
261};
262
263//main
264void main(MyThread & this) {
265        //...
266}
267
268void foo() {
269        MyThread thrds[10];
270        //Start 10 threads at the beginning of the scope
271
272        DoStuff();
273
274        //Wait for the 10 threads to finish
275}
276\end{cfacode}
277
278However, one of the apparent drawbacks of this system is that threads now always form a lattice, that is they are always destroyed in opposite order of construction because of block structure. However, storage allocation is not limited to blocks; dynamic allocation can create threads that outlive the scope in which the thread is created much like dynamically allocating memory lets objects outlive the scope in which they are created
279
280\begin{cfacode}
281thread MyThread {
282        //...
283};
284
285//main
286void main(MyThread & this) {
287        //...
288}
289
290void foo() {
291        MyThread * long_lived;
292        {
293                MyThread short_lived;
294                //Start a thread at the beginning of the scope
295
296                DoStuff();
297
298                //create another thread that will outlive the thread in this scope
299                long_lived = new MyThread;
300
301                //Wait for the thread short_lived to finish
302        }
303        DoMoreStuff();
304
305        //Now wait for the short_lived to finish
306        delete long_lived;
307}
308\end{cfacode}
Note: See TracBrowser for help on using the repository browser.