Changeset 21a1efb for doc/proposals/concurrency/text/basics.tex
- Timestamp:
- Sep 12, 2017, 4:06:56 PM (7 years ago)
- 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
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/proposals/concurrency/text/basics.tex
r416cc86 r21a1efb 1 1 % ====================================================================== 2 2 % ====================================================================== 3 \chapter{Basics} 3 \chapter{Basics}\label{basics} 4 4 % ====================================================================== 5 5 % ====================================================================== … … 13 13 14 14 \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 to do with parallelism and arguably little to do with concurrency, coroutines need to deal with context-switchs andand 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}.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 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 16 17 17 Here is an example of a solution to the fibonnaci problem using \CFA coroutines: … … 21 21 }; 22 22 23 void ?{}(Fibonacci *this) { // constructor24 this ->fn = 0;23 void ?{}(Fibonacci & this) { // constructor 24 this.fn = 0; 25 25 } 26 26 27 27 // main automacically called on first resume 28 void main(Fibonacci *this) {28 void main(Fibonacci & this) { 29 29 int fn1, fn2; // retained between resumes 30 this ->fn = 0;31 fn1 = this ->fn;30 this.fn = 0; 31 fn1 = this.fn; 32 32 suspend(this); // return to last resume 33 33 34 this ->fn = 1;34 this.fn = 1; 35 35 fn2 = fn1; 36 fn1 = this ->fn;36 fn1 = this.fn; 37 37 suspend(this); // return to last resume 38 38 39 39 for ( ;; ) { 40 this ->fn = fn1 + fn2;40 this.fn = fn1 + fn2; 41 41 fn2 = fn1; 42 fn1 = this ->fn;42 fn1 = this.fn; 43 43 suspend(this); // return to last resume 44 44 } 45 45 } 46 46 47 int next(Fibonacci *this) {47 int next(Fibonacci & this) { 48 48 resume(this); // transfer to last suspend 49 49 return this.fn; … … 53 53 Fibonacci f1, f2; 54 54 for ( int i = 1; i <= 10; i += 1 ) { 55 sout | next( &f1) | next(&f2) | endl;55 sout | next( f1 ) | next( f2 ) | endl; 56 56 } 57 57 } … … 106 106 }; 107 107 108 void ?{}(Fibonacci *this) {109 this ->fn = 0;110 ( &this->c){};108 void ?{}(Fibonacci & this) { 109 this.fn = 0; 110 (this.c){}; 111 111 } 112 112 \end{cfacode} … … 126 126 \subsection{Alternative: Lamda Objects} 127 127 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: 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: 129 129 \begin{cfacode} 130 130 asymmetric_coroutine<>::pull_type … … 132 132 symmetric_coroutine<>::call_type 133 133 symmetric_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} 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 : 138 138 \begin{cfacode} 139 139 void foo( coroutine_t cid, void * arg ) { … … 152 152 \subsection{Alternative: Trait-based coroutines} 153 153 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.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. 155 155 156 156 \begin{cfacode} 157 157 trait 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} 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. 163 163 164 164 \begin{center} … … 174 174 }; 175 175 176 static inline 177 coroutine_desc * get_coroutine( 178 struct MyCoroutine * this176 static inline 177 coroutine_desc * get_coroutine( 178 struct MyCoroutine & this 179 179 ) { 180 return &this ->__cor;180 return &this.__cor; 181 181 } 182 182 … … 186 186 \end{center} 187 187 188 188 The 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 189 190 190 \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:191 The 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 192 193 193 \begin{cfacode} … … 199 199 \begin{cfacode} 200 200 trait 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); 204 204 }; 205 205 \end{cfacode} … … 209 209 thread foo {}; 210 210 211 void main(foo *this) {211 void main(foo & this) { 212 212 sout | "Hello World!" | endl; 213 213 } … … 223 223 224 224 //ctor 225 void ?{}(FuncRunner *this, voidFunc inFunc) {226 func = inFunc;225 void ?{}(FuncRunner & this, voidFunc inFunc) { 226 this.func = inFunc; 227 227 } 228 228 229 229 //main 230 void main(FuncRunner *this) {231 this ->func();230 void main(FuncRunner & this) { 231 this.func(); 232 232 } 233 233 \end{cfacode} … … 239 239 thread World; 240 240 241 void main( thread World*this) {241 void main(World & this) { 242 242 sout | "World!" | endl; 243 243 } … … 257 257 258 258 \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 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 271 272 DoStuff(); 273 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 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} 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 271 295 272 296 DoStuff(); 273 297 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.