source: doc/proposals/concurrency/text/basics.tex @ 27dde72

Last change on this file since 27dde72 was 27dde72, checked in by Thierry Delisle <tdelisle@…>, 6 years ago

Major update to the concurrency proposal to be based on multiple files

  • Property mode set to 100644
File size: 15.6 KB
1% ======================================================================
2% ======================================================================
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.
8\section{Basics of concurrency}
9At its core, concurrency is based on having multiple call stacks and potentially multiple threads of execution for these stacks. Concurrency alone 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 but in any case a subset of concurrency related challenges start to appear. For the complete set of concurrency challenges to be present, the only feature missing is preemption. Indeed, concurrency challenges appear with the lack of determinism. Guaranteeing mutual-exclusion or synchronisation are simply ways of limiting the lack of determinism in the system. A scheduler introduces order of execution uncertainty while preemption introduces incertainty about when 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 the user the illusion that hundred of tasks are running in parallel. Optimal performance in concurrent applications is often obtained by having as little determinism as correctness will allow\cit.
11\section{\protect\CFA 's Thread Building Blocks}
12% As a system-level language, \CFA should offer both performance and flexibilty as its primary goals, simplicity and user-friendliness being a secondary concern. Therefore, the core of parallelism in \CFA should prioritize power and efficiency. With this said, deconstructing popular paradigms in order to get simple building blocks yields \glspl{uthread} as the core parallelism block. \Glspl{pool} and other parallelism paradigms can then be built on top of the underlying threading model.
13One of the important features that is missing to C is threading. On modern architectures, the lack of threading is becoming less and less forgivable\cite{Sutter05, Sutter05b} and therefore any modern programming language should 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 an a way that is as natural as possible to programmers used to imperative languages. And being a system level language means programmers will expect to be able to choose precisely which features they need and which cost they are willing to pay.
15\section{Coroutines : A stepping stone}\label{coroutine}
16While 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 the concurrency system. Indeed, while having nothing todo with parallelism and arguably little to do with concurrency, coroutines need to deal with context-switchs and and other context management operations. Therefore, this proposal includes coroutines both as an intermediate step for the implementation of threads and a first class feature of \CFA. Furthermore, many design challenges of threads are at least partially present in designing coroutines, which makes the design effort that much more relevant.
18The core API of coroutines revolve around two features : independent call stacks and \code{suspend}/\code{resume}.
19Here is an example of a solution to the fibonnaci problem using \CFA coroutines :
21        coroutine Fibonacci {
22              int fn; // used for communication
23        };
25        void ?{}(Fibonacci* this) { // constructor
26              this->fn = 0;
27        }
29        void main(Fibonacci* this) {
30                int fn1, fn2;           // retained between resumes
31                this->fn = 0;
32                fn1 = this->fn;
33                suspend(this);          // return to last resume
35                this->fn = 1;
36                fn2 = fn1;
37                fn1 = this->fn;
38                suspend(this);          // return to last resume
40                for ( ;; ) {
41                        this->fn = fn1 + fn2;
42                        fn2 = fn1;
43                        fn1 = this->fn;
44                        suspend(this);  // return to last resume
45                }
46        }
48        int next(Fibonacci* this) {
49                resume(this); // transfer to last suspend
50                return this.fn;
51        }
53        void main() { // regular program main
54                Fibonacci f1, f2;
55                for ( int i = 1; i <= 10; i += 1 ) {
56                        sout | next(&f1) | next(&f2) | endl;
57                }
58        }
62One important design challenge for coroutines and threads (shown in section \ref{threads}) is that the runtime system needs to run some code after the user-constructor runs. In the case of the coroutines this challenge is simpler since there is no loss of determinism brough by preemption or scheduling, however, the underlying challenge remains the same for coroutines and threads.
64The 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 (Obviously we only solve cases where these two statements don't conflict). There are several solutions to this problem but the chosen options effectively forces the design of the coroutine.
66Furthermore, \CFA faces an extra challenge which is that polymorphique routines rely on invisible thunks when casted to non-polymorphic routines and these thunks have function scope. For example, the following code, while looking benign, can run into undefined behaviour because of thunks :
69//async: Runs function asynchronously on another thread
70forall(otype T)
71extern void async(void (*func)(T*), T* obj);
73forall(otype T)
74void noop(T *) {}
76void bar() {
77        int a;
78        async(noop, &a);
81Indeed, the generated C code\footnote{Code trimmed down for brevity} shows that a local thunk is created in order to hold type information :
84extern void async(/* omitted */, void (*func)(void *), void *obj);
86void noop(/* omitted */, void *obj){}
88void bar(){
89        int a;
90        void _thunk0(int *_p0){
91                /* omitted */
92                noop(/* omitted */, _p0);
93        }
94        /* omitted */
95        async(/* omitted */, ((void (*)(void *))(&_thunk0)), (&a));
98The problem in the this example is that there 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.
100\subsection{Alternative: Composition}
101One solution to this challenge would be to use inheritence,
104        struct Fibonacci {
105              int fn; // used for communication
106              coroutine c;
107        };
109        void ?{}(Fibonacci* this) {
110              this->fn = 0;
111                (&this->c){};
112        }
115There 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 we use a parameter or a virtual pointer, this means the coroutine data must be made larger to store a value that is actually a compile time constant (The address of the main routine). The second problem which is both subtle but significant, is that now users can get the initialisation order of there coroutines wrong. Indeed, every field of a \CFA struct will be constructed but in the order of declaration, unless users explicitly write otherwise. This means that users who forget to initialize a the coroutine at the right time may resume the coroutine with an uninitilized object. For coroutines, this is unlikely to be a problem, for threads however, this is a significant problem.
117\subsection{Alternative: Reserved keyword}
118The next alternative is to use language support to annotate coroutines as follows :
121        coroutine Fibonacci {
122              int fn; // used for communication
123        };
126This 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.
127While 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.
129\subsection{Alternative: Lamda Objects}
131For 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 : \code{asymmetric_coroutine<>::pull_type}, \code{asymmetric_coroutine<>::push_type}, \code{symmetric_coroutine<>::call_type}, \code{symmetric_coroutine<>::yield_type}. Often, the canonical threading paradigm in languages is based on function pointers, pthread being one of the most well known example. The main problem of these 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 and \CFA and solves several issues, added support for routine/lambda based coroutines adds very little.
133\subsection{Trait based coroutines}
135Finally the underlying approach, which is the one closest to \CFA idioms, is to use trait-based lazy coroutines. This approach defines a coroutine as \say{anything that \say{satisfies the trait \code{is_coroutine} and is used as a coroutine} is a coroutine}.
138trait is_coroutine(dtype T) {
139      void main(T * this);
140      coroutine_desc * get_coroutine(T * this);
144This entails that 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.
147\section{Thread Interface}\label{threads}
148The basic building blocks of multi-threading in \CFA are \glspl{cfathread}. By default these are implemented as \glspl{uthread}, and as such, offer a flexible and lightweight threading interface (lightweight compared to \glspl{kthread}). A thread can be declared using a SUE declaration \code{thread} as follows :
151        thread foo {};
154Like for coroutines, the keyword is a thin wrapper arount a \CFA trait :
157trait is_thread(dtype T) {
158      void ^?{}(T* mutex this);
159      void main(T* this);
160      thread_desc* get_thread(T* this);
164Obviously, 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 :
166        thread foo {};
168        void main(foo* this) {
169                sout | "Hello World!" | endl;
170        }
173In this example, threads of type \code{foo} will start there execution in the \code{void main(foo*)} routine which in this case prints \code{"Hello World!"}. While this proposoal encourages this approach which enforces strongly type programming, users may prefer to use the routine based thread semantics for the sake of simplicity. With these semantics it is trivial to write a thread type that takes a function pointer as parameter and executes it on its stack asynchronously :
175        typedef void (*voidFunc)(void);
177        thread FuncRunner {
178                voidFunc func;
179        };
181        //ctor
182        void ?{}(FuncRunner* this, voidFunc inFunc) {
183                func = inFunc;
184        }
186        //main
187        void main(FuncRunner* this) {
188                this->func();
189        }
192An 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.
194Of 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.
196thread World;
198void main(thread World* this) {
199        sout | "World!" | endl;
202void main() {
203        World w;
204        //Thread run forks here
206        //Printing "Hello " and "World!" will be run concurrently
207        sout | "Hello " | endl;
209        //Implicit join at end of scope
213This semantic has several advantages over explicit semantics : typesafety is guaranteed, a thread is always started and stopped exaclty once and users cannot make any progamming errors. However, one of the apparent drawbacks of this system is that threads now always form a lattice, that is they are always destroyed in opposite order of construction. While this seems like a significant limitation, existing \CFA semantics can solve this problem. Indeed, using dynamic allocation to create threads will naturally let threads outlive the scope in which the thread was created much like dynamically allocating memory will let objects outlive the scope in which thy were created :
216        thread MyThread {
217                //...
218        };
220        //main
221        void main(MyThread* this) {
222                //...
223        }
225        void foo() {
226                MyThread* long_lived;
227                {
228                        MyThread short_lived;
229                        //Start a thread at the beginning of the scope
231                        DoStuff();
233                        //create another thread that will outlive the thread in this scope
234                        long_lived = new MyThread;
236                        //Wait for the thread short_lived to finish
237                }
238                DoMoreStuff();
240                //Now wait for the short_lived to finish
241                delete long_lived;
242        }
245Another advantage of this semantic is that it naturally scale to multiple threads meaning basic synchronisation is very simple :
248        thread MyThread {
249                //...
250        };
252        //main
253        void main(MyThread* this) {
254                //...
255        }
257        void foo() {
258                MyThread thrds[10];
259                //Start 10 threads at the beginning of the scope
261                DoStuff();
263                //Wait for the 10 threads to finish
264        }
Note: See TracBrowser for help on using the repository browser.