Ignore:
Timestamp:
Sep 12, 2017, 4:06:56 PM (7 years ago)
Author:
Thierry Delisle <tdelisle@…>
Branches:
ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
Children:
b2e2e34
Parents:
416cc86
Message:

Sent a draft to peter

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/proposals/concurrency/text/basics.tex

    r416cc86 r21a1efb  
    11% ======================================================================
    22% ======================================================================
    3 \chapter{Basics}
     3\chapter{Basics}\label{basics}
    44% ======================================================================
    55% ======================================================================
     
    1313
    1414\section{Coroutines: A stepping stone}\label{coroutine}
    15 While 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 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. The core API of coroutines revolve around two features: independent call stacks and \code{suspend}/\code{resume}.
     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}.
    1616
    1717Here is an example of a solution to the fibonnaci problem using \CFA coroutines:
     
    2121        };
    2222
    23         void ?{}(Fibonacci* this) { // constructor
    24               this->fn = 0;
     23        void ?{}(Fibonacci & this) { // constructor
     24              this.fn = 0;
    2525        }
    2626
    2727        // main automacically called on first resume
    28         void main(Fibonacci* this) {
     28        void main(Fibonacci & this) {
    2929                int fn1, fn2;           // retained between resumes
    30                 this->fn = 0;
    31                 fn1 = this->fn;
     30                this.fn = 0;
     31                fn1 = this.fn;
    3232                suspend(this);          // return to last resume
    3333
    34                 this->fn = 1;
     34                this.fn = 1;
    3535                fn2 = fn1;
    36                 fn1 = this->fn;
     36                fn1 = this.fn;
    3737                suspend(this);          // return to last resume
    3838
    3939                for ( ;; ) {
    40                         this->fn = fn1 + fn2;
     40                        this.fn = fn1 + fn2;
    4141                        fn2 = fn1;
    42                         fn1 = this->fn;
     42                        fn1 = this.fn;
    4343                        suspend(this);  // return to last resume
    4444                }
    4545        }
    4646
    47         int next(Fibonacci* this) {
     47        int next(Fibonacci & this) {
    4848                resume(this); // transfer to last suspend
    4949                return this.fn;
     
    5353                Fibonacci f1, f2;
    5454                for ( int i = 1; i <= 10; i += 1 ) {
    55                         sout | next(&f1) | next(&f2) | endl;
     55                        sout | next( f1 ) | next( f2 ) | endl;
    5656                }
    5757        }
     
    106106        };
    107107
    108         void ?{}(Fibonacci* this) {
    109               this->fn = 0;
    110                 (&this->c){};
     108        void ?{}(Fibonacci & this) {
     109              this.fn = 0;
     110                (this.c){};
    111111        }
    112112\end{cfacode}
     
    126126\subsection{Alternative: Lamda Objects}
    127127
    128 For 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: 
     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:
    129129\begin{cfacode}
    130130asymmetric_coroutine<>::pull_type
     
    132132symmetric_coroutine<>::call_type
    133133symmetric_coroutine<>::yield_type
    134 \end{cfacode} 
    135 Often, 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 
    137 A variation of this would be to use an simple function pointer in the same way pthread does for threads : 
     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 :
    138138\begin{cfacode}
    139139void foo( coroutine_t cid, void * arg ) {
     
    152152\subsection{Alternative: Trait-based coroutines}
    153153
    154 Finally 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 is a coroutine.
     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.
    155155
    156156\begin{cfacode}
    157157trait is_coroutine(dtype T) {
    158       void main(T * this);
    159       coroutine_desc * get_coroutine(T * this);
    160 };
    161 \end{cfacode}
    162 This 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. 
     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.
    163163
    164164\begin{center}
     
    174174};
    175175
    176 static inline 
    177 coroutine_desc * get_coroutine( 
    178         struct MyCoroutine * this
     176static inline
     177coroutine_desc * get_coroutine(
     178        struct MyCoroutine & this
    179179) {
    180         return &this->__cor;
     180        return &this.__cor;
    181181}
    182182
     
    186186\end{center}
    187187
    188 
     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.
    189189
    190190\section{Thread Interface}\label{threads}
    191 The basic building blocks of multi-threading in \CFA are \glspl{cfathread}. Both use 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:
     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:
    192192
    193193\begin{cfacode}
     
    199199\begin{cfacode}
    200200trait is_thread(dtype T) {
    201       void ^?{}(T* mutex this);
    202       void main(T* this);
    203       thread_desc* get_thread(T* this);
     201      void ^?{}(T & mutex this);
     202      void main(T & this);
     203      thread_desc* get_thread(T & this);
    204204};
    205205\end{cfacode}
     
    209209        thread foo {};
    210210
    211         void main(foo* this) {
     211        void main(foo & this) {
    212212                sout | "Hello World!" | endl;
    213213        }
     
    223223
    224224        //ctor
    225         void ?{}(FuncRunner* this, voidFunc inFunc) {
    226                 func = inFunc;
     225        void ?{}(FuncRunner & this, voidFunc inFunc) {
     226                this.func = inFunc;
    227227        }
    228228
    229229        //main
    230         void main(FuncRunner* this) {
    231                 this->func();
     230        void main(FuncRunner & this) {
     231                this.func();
    232232        }
    233233\end{cfacode}
     
    239239thread World;
    240240
    241 void main(thread World* this) {
     241void main(World & this) {
    242242        sout | "World!" | endl;
    243243}
     
    257257
    258258\begin{cfacode}
    259         thread MyThread {
    260                 //...
    261         };
    262 
    263         //main
    264         void main(MyThread* this) {
    265                 //...
    266         }
    267 
    268         void foo() {
    269                 MyThread thrds[10];
    270                 //Start 10 threads at the beginning of the scope
     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
    271295
    272296                DoStuff();
    273297
    274                 //Wait for the 10 threads to finish
    275         }
    276 \end{cfacode}
    277 
    278 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 because of block structure. However, storage allocation os 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}
    281         thread MyThread {
    282                 //...
    283         };
    284 
    285         //main
    286         void main(MyThread* this) {
    287                 //...
    288         }
    289 
    290         void 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}
     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 TracChangeset for help on using the changeset viewer.