Changes in doc/proposals/concurrency/text/basics.tex [21a1efb:7c17511]

File:

• doc/proposals/concurrency/text/basics.tex (modified) (15 diffs)

doc/proposals/concurrency/text/basics.tex

@@ -1 +1 @@
 % ======================================================================
 % ======================================================================
-\chapter{Basics}\label{basics}
+\chapter{Basics}
 % ======================================================================
 % ======================================================================
@@ -13 +13 @@
 
 \section{Coroutines: A stepping stone}\label{coroutine}
-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}.
+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}.
 
 Here is an example of a solution to the fibonnaci problem using \CFA coroutines:
@@ -21 +21 @@
         };
 
-        void ?{}(Fibonacci & this) { // constructor
-              this.fn = 0;
+        void ?{}(Fibonacci* this) { // constructor
+              this->fn = 0;
         }
 
         // main automacically called on first resume
-        void main(Fibonacci & this) {
+        void main(Fibonacci* this) {
                 int fn1, fn2;           // retained between resumes
-                this.fn = 0;
-                fn1 = this.fn;
+                this->fn = 0;
+                fn1 = this->fn;
                 suspend(this);          // return to last resume
 
-                this.fn = 1;
+                this->fn = 1;
                 fn2 = fn1;
-                fn1 = this.fn;
+                fn1 = this->fn;
                 suspend(this);          // return to last resume
 
                 for ( ;; ) {
-                        this.fn = fn1 + fn2;
+                        this->fn = fn1 + fn2;
                         fn2 = fn1;
-                        fn1 = this.fn;
+                        fn1 = this->fn;
                         suspend(this);  // return to last resume
                 }
         }
 
-        int next(Fibonacci & this) {
+        int next(Fibonacci* this) {
                 resume(this); // transfer to last suspend
                 return this.fn;
@@ -53 +53 @@
                 Fibonacci f1, f2;
                 for ( int i = 1; i <= 10; i += 1 ) {
-                        sout | next( f1 ) | next( f2 ) | endl;
+                        sout | next(&f1) | next(&f2) | endl;
                 }
         }
@@ -106 +106 @@
         };
 
-        void ?{}(Fibonacci & this) {
-              this.fn = 0;
-                (this.c){};
+        void ?{}(Fibonacci* this) {
+              this->fn = 0;
+                (&this->c){};
         }
 \end{cfacode}
@@ -126 +126 @@
 \subsection{Alternative: Lamda Objects}
 
-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:
+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: 
 \begin{cfacode}
 asymmetric_coroutine<>::pull_type
@@ -132 +132 @@
 symmetric_coroutine<>::call_type
 symmetric_coroutine<>::yield_type
-\end{cfacode}
-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.
-
-A variation of this would be to use an simple function pointer in the same way pthread does for threads :
+\end{cfacode} 
+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. 
+
+A variation of this would be to use an simple function pointer in the same way pthread does for threads : 
 \begin{cfacode}
 void foo( coroutine_t cid, void * arg ) {
@@ -152 +152 @@
 \subsection{Alternative: Trait-based coroutines}
 
-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.
+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. 
 
 \begin{cfacode}
 trait is_coroutine(dtype T) {
-      void main(T & this);
-      coroutine_desc * get_coroutine(T & this);
+      void main(T * this);
+      coroutine_desc * get_coroutine(T * this);
 };
 \end{cfacode}
-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.
+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. 
 
 \begin{center}
@@ -174 +174 @@
 };
 
-static inline
-coroutine_desc * get_coroutine(
-        struct MyCoroutine & this
+static inline 
+coroutine_desc * get_coroutine( 
+        struct MyCoroutine * this 
 ) {
-        return &this.__cor;
+        return &this->__cor;
 }
 
@@ -186 +186 @@
 \end{center}
 
-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.
+
 
 \section{Thread Interface}\label{threads}
-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:
+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:
 
 \begin{cfacode}
@@ -199 +199 @@
 \begin{cfacode}
 trait is_thread(dtype T) {
-      void ^?{}(T & mutex this);
-      void main(T & this);
-      thread_desc* get_thread(T & this);
+      void ^?{}(T* mutex this);
+      void main(T* this);
+      thread_desc* get_thread(T* this);
 };
 \end{cfacode}
@@ -209 +209 @@
         thread foo {};
 
-        void main(foo & this) {
+        void main(foo* this) {
                 sout | "Hello World!" | endl;
         }
@@ -223 +223 @@
 
         //ctor
-        void ?{}(FuncRunner & this, voidFunc inFunc) {
-                this.func = inFunc;
+        void ?{}(FuncRunner* this, voidFunc inFunc) {
+                func = inFunc;
         }
 
         //main
-        void main(FuncRunner & this) {
-                this.func();
+        void main(FuncRunner* this) {
+                this->func();
         }
 \end{cfacode}
@@ -239 +239 @@
 thread World;
 
-void main(World & this) {
+void main(thread World* this) {
         sout | "World!" | endl;
 }
@@ -257 +257 @@
 
 \begin{cfacode}
-thread MyThread {
-        //...
-};
-
-//main
-void main(MyThread & this) {
-        //...
-}
-
-void foo() {
-        MyThread thrds[10];
-        //Start 10 threads at the beginning of the scope
-
-        DoStuff();
-
-        //Wait for the 10 threads to finish
-}
-\end{cfacode}
-
-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
-
-\begin{cfacode}
-thread MyThread {
-        //...
-};
-
-//main
-void main(MyThread & this) {
-        //...
-}
-
-void foo() {
-        MyThread * long_lived;
-        {
-                MyThread short_lived;
-                //Start a thread at the beginning of the scope
+        thread MyThread {
+                //...
+        };
+
+        //main
+        void main(MyThread* this) {
+                //...
+        }
+
+        void foo() {
+                MyThread thrds[10];
+                //Start 10 threads at the beginning of the scope
 
                 DoStuff();
 
-                //create another thread that will outlive the thread in this scope
-                long_lived = new MyThread;
-
-                //Wait for the thread short_lived to finish
-        }
-        DoMoreStuff();
-
-        //Now wait for the short_lived to finish
-        delete long_lived;
-}
-\end{cfacode}
+                //Wait for the 10 threads to finish
+        }
+\end{cfacode}
+
+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
+
+\begin{cfacode}
+        thread MyThread {
+                //...
+        };
+
+        //main
+        void main(MyThread* this) {
+                //...
+        }
+
+        void foo() {
+                MyThread* long_lived;
+                {
+                        MyThread short_lived;
+                        //Start a thread at the beginning of the scope
+
+                        DoStuff();
+
+                        //create another thread that will outlive the thread in this scope
+                        long_lived = new MyThread;
+
+                        //Wait for the thread short_lived to finish
+                }
+                DoMoreStuff();
+
+                //Now wait for the short_lived to finish
+                delete long_lived;
+        }
+\end{cfacode}