[6e7b969] | 1 | \chapter{\CFA{} Existing Features} |
---|
| 2 | |
---|
| 3 | \section{Overloading and extern} |
---|
| 4 | Cforall has overloading, allowing multiple definitions of the same name to |
---|
| 5 | be defined. |
---|
| 6 | |
---|
| 7 | This also adds name mangling so that the assembly symbols are unique for |
---|
| 8 | different overloads. For compatability with names in C there is also a |
---|
| 9 | syntax to diable the name mangling. These unmangled names cannot be overloaded |
---|
| 10 | but act as the interface between C and \CFA code. |
---|
| 11 | |
---|
| 12 | The syntax for disabling mangling is: |
---|
| 13 | \begin{lstlisting} |
---|
| 14 | extern "C" { |
---|
| 15 | ... |
---|
| 16 | } |
---|
| 17 | \end{lstlisting} |
---|
| 18 | |
---|
| 19 | To re-enable mangling once it is disabled the syntax is: |
---|
| 20 | \begin{lstlisting} |
---|
| 21 | extern "Cforall" { |
---|
| 22 | ... |
---|
| 23 | } |
---|
| 24 | \end{lstlisting} |
---|
| 25 | |
---|
| 26 | Both should occur at the declaration level and effect all the declarations |
---|
| 27 | in \texttt{...}. Neither care about the state of mangling when they begin |
---|
| 28 | and will return to that state after the group is finished. So re-enabling |
---|
| 29 | is only used to nest areas of mangled and unmangled declarations. |
---|
| 30 | |
---|
| 31 | \section{References} |
---|
| 32 | \CFA adds references to C. These are auto-dereferencing pointers and use the |
---|
| 33 | same syntax as pointers except they use ampersand (\codeCFA{\&}) instead of |
---|
| 34 | the asterisk (\codeCFA{*}). They can also be constaint or mutable, if they |
---|
| 35 | are mutable they may be assigned to by using the address-of operator |
---|
| 36 | (\codeCFA\&) which converts them into a pointer. |
---|
| 37 | |
---|
| 38 | \section{Constructors and Destructors} |
---|
| 39 | |
---|
| 40 | Both constructors and destructors are operators, which means they are just |
---|
| 41 | functions with special names. The special names are used to define them and |
---|
| 42 | may be used to call the functions expicately. The \CFA special names are |
---|
| 43 | constructed by taking the tokens in the operators and putting \texttt{?} where |
---|
| 44 | the arguments would go. So multiplication is \texttt{?*?} while dereference |
---|
| 45 | is \texttt{*?}. This also make it easy to tell the difference between |
---|
| 46 | pre-fix operations (such as \texttt{++?}) and post-fix operations |
---|
| 47 | (\texttt{?++}). |
---|
| 48 | |
---|
| 49 | The special name for contructors is \texttt{?\{\}}, which comes from the |
---|
| 50 | initialization syntax in C. The special name for destructors is |
---|
| 51 | \texttt{\^{}?\{\}}. % I don't like the \^{} symbol but $^\wedge$ isn't better. |
---|
| 52 | |
---|
| 53 | Any time a type T goes out of scope the destructor matching |
---|
| 54 | \codeCFA{void ^?\{\}(T \&);} is called. In theory this is also true of |
---|
| 55 | primitive types such as \codeCFA{int}, but in practice those are no-ops and |
---|
| 56 | are usually omitted for optimization. |
---|
| 57 | |
---|
| 58 | \section{Polymorphism} |
---|
| 59 | \CFA uses polymorphism to create functions and types that are defined over |
---|
| 60 | different types. \CFA polymorphic declarations serve the same role as \CPP |
---|
| 61 | templates or Java generics. |
---|
| 62 | |
---|
| 63 | Polymorphic declaractions start with a forall clause that goes before the |
---|
| 64 | standard (monomorphic) declaration. These declarations have the same syntax |
---|
| 65 | except that you may use the names introduced by the forall clause in them. |
---|
| 66 | |
---|
| 67 | Forall clauses are written \codeCFA{forall( ... )} where \codeCFA{...} becomes |
---|
| 68 | the list of polymorphic variables (local type names) and assertions, which |
---|
| 69 | repersent required operations on those types. |
---|
| 70 | |
---|
| 71 | \begin{lstlisting} |
---|
| 72 | forall(dtype T | { void do_once(T &); }) |
---|
| 73 | void do_twice(T & value) { |
---|
| 74 | do_once(value); |
---|
| 75 | do_once(value); |
---|
| 76 | } |
---|
| 77 | \end{lstlisting} |
---|
| 78 | |
---|
| 79 | A polymorphic function can be used in the same way normal functions are. |
---|
| 80 | The polymorphics variables are filled in with concrete types and the |
---|
| 81 | assertions are checked. An assertion checked by seeing if that name of that |
---|
| 82 | type (with all the variables replaced with the concrete types) is defined at |
---|
| 83 | the the call site. |
---|
| 84 | |
---|
[d435c04] | 85 | As an example, even if no function named \codeCFA{do_once} is not defined |
---|
| 86 | near the definition of \codeCFA{do_twice} the following code will work. |
---|
[6e7b969] | 87 | \begin{lstlisting} |
---|
| 88 | int quadruple(int x) { |
---|
| 89 | void do_once(int & y) { |
---|
| 90 | y = y * 2; |
---|
| 91 | } |
---|
| 92 | do_twice(x); |
---|
| 93 | return x; |
---|
| 94 | } |
---|
| 95 | \end{lstlisting} |
---|
| 96 | This is not the recommended way to implement a quadruple function but it |
---|
[d435c04] | 97 | does work. The complier will deduce that \codeCFA{do_twice}'s T is an |
---|
[6e7b969] | 98 | integer from the argument. It will then look for a definition matching the |
---|
[d435c04] | 99 | assertion which is the \codeCFA{do_once} defined within the function. That |
---|
| 100 | function will be passed in as a function pointer to \codeCFA{do_twice} and |
---|
[6e7b969] | 101 | called within it. |
---|
| 102 | |
---|
| 103 | To avoid typing out long lists of assertions again and again there are also |
---|
| 104 | traits which collect assertions into convenent packages that can then be used |
---|
| 105 | in assertion lists instead of all of their components. |
---|
| 106 | \begin{lstlisting} |
---|
| 107 | trait done_once(dtype T) { |
---|
| 108 | void do_once(T &); |
---|
| 109 | } |
---|
| 110 | \end{lstlisting} |
---|
| 111 | |
---|
| 112 | After this the forall list in the previous example could instead be written |
---|
| 113 | with the trait instead of the assertion itself. |
---|
| 114 | \begin{lstlisting} |
---|
| 115 | forall(dtype T | done_once(T)) |
---|
| 116 | \end{lstlisting} |
---|
| 117 | |
---|
| 118 | Traits can have arbitrary number of assertions in them and are usually used to |
---|
| 119 | create short hands for, and give descriptive names to, commond groupings of |
---|
| 120 | assertions. |
---|
| 121 | |
---|
| 122 | Polymorphic structures and unions may also be defined by putting a forall |
---|
| 123 | clause before the declaration. The type variables work the same way except |
---|
| 124 | are now used in field declaractions instead of parameters and local variables. |
---|
| 125 | |
---|
| 126 | \begin{lstlisting} |
---|
| 127 | forall(dtype T) |
---|
| 128 | struct node { |
---|
| 129 | node(T) * next; |
---|
| 130 | T * data; |
---|
| 131 | } |
---|
| 132 | \end{lstlisting} |
---|
| 133 | |
---|
| 134 | The \codeCFA{node(T)} is a use of a polymorphic structure. Polymorphic types |
---|
| 135 | must be provided their polymorphic parameters. |
---|
| 136 | |
---|
| 137 | There are many other features of polymorphism that have not given here but |
---|
| 138 | these are the ones used by the exception system. |
---|
| 139 | |
---|
| 140 | \section{Concurrency} |
---|
| 141 | |
---|
| 142 | \CFA has a number of concurrency features, \codeCFA{thread}s, |
---|
| 143 | \codeCFA{monitor}s and \codeCFA{mutex} parameters, \codeCFA{coroutine}s and |
---|
| 144 | \codeCFA{generator}s. The two features that interact with the exception system |
---|
| 145 | are \codeCFA{thread}s and \codeCFA{coroutine}s; they and their supporting |
---|
| 146 | constructs will be described here. |
---|
| 147 | |
---|
| 148 | \subsection{Coroutines} |
---|
| 149 | Coroutines are routines that do not have to finish execution to hand control |
---|
| 150 | back to their caller, instead they may suspend their execution at any time |
---|
| 151 | and resume it later. |
---|
| 152 | Coroutines are not true concurrency but share some similarities and many of |
---|
| 153 | the same underpinnings and so are included as part of the \CFA threading |
---|
| 154 | library. |
---|
| 155 | |
---|
| 156 | In \CFA coroutines are created using the \codeCFA{coroutine} keyword which |
---|
| 157 | works just like \codeCFA{struct} except that the created structure will be |
---|
[d435c04] | 158 | modified by the compiler to satify the \codeCFA{is_coroutine} trait. |
---|
[6e7b969] | 159 | |
---|
| 160 | These structures act as the interface between callers and the coroutine, |
---|
| 161 | the fields are used to pass information in and out. Here is a simple example |
---|
| 162 | where the single field is used to pass the next number in a sequence out. |
---|
| 163 | \begin{lstlisting} |
---|
| 164 | coroutine CountUp { |
---|
| 165 | unsigned int next; |
---|
| 166 | } |
---|
| 167 | \end{lstlisting} |
---|
| 168 | |
---|
| 169 | The routine part of the coroutine is a main function for the coroutine. It |
---|
| 170 | takes a reference to a coroutine object and returns nothing. In this function, |
---|
| 171 | and any functions called by this function, the suspend statement may be used |
---|
| 172 | to return execution to the coroutine's caller. When control returns to the |
---|
| 173 | function it continue from that same suspend statement instead of at the top |
---|
| 174 | of the function. |
---|
| 175 | \begin{lstlisting} |
---|
| 176 | void main(CountUp & this) { |
---|
| 177 | unsigned int next = 0; |
---|
| 178 | while (true) { |
---|
| 179 | this.next = next; |
---|
| 180 | suspend; |
---|
| 181 | next = next + 1; |
---|
| 182 | } |
---|
| 183 | } |
---|
| 184 | \end{lstlisting} |
---|
| 185 | |
---|
| 186 | Control is passed to the coroutine with the resume function. This includes the |
---|
| 187 | first time when the coroutine is starting up. The resume function takes a |
---|
| 188 | reference to the coroutine structure and returns the same reference. The |
---|
| 189 | return value is for easy access to communication variables. For example the |
---|
| 190 | next value from a count-up can be generated and collected in a single |
---|
| 191 | expression: \codeCFA{resume(count).next}. |
---|
| 192 | |
---|
| 193 | \subsection{Monitors and Mutex} |
---|
| 194 | |
---|
| 195 | True concurrency does not garrenty ordering. To get some of that ordering back |
---|
| 196 | \CFA uses monitors and mutex (mutual exclution) parameters. A monitor is |
---|
| 197 | another special declaration that contains a lock and is compatable with mutex |
---|
| 198 | parameters. |
---|
| 199 | |
---|
| 200 | Function parameters can have the \codeCFA{mutex} qualifiers on reference |
---|
| 201 | arguments, for example \codeCFA{void example(a_monitor & mutex arg);}. When the |
---|
| 202 | function is called it will acquire the lock on all of the mutex parameters. |
---|
| 203 | |
---|
| 204 | This means that all functions that mutex on a type are part of a critical |
---|
| 205 | section and only one will ever run at a time. |
---|
| 206 | |
---|
| 207 | \subsection{Threads} |
---|
| 208 | While coroutines allow new things to be done with a single execution path |
---|
| 209 | threads actually introduce new paths of execution that continue independently. |
---|
| 210 | Now for threads to work together their must be some communication between them |
---|
| 211 | and that means the timing of certain operations does have to be known. There |
---|
| 212 | or various means of syncronization and mutual exclution provided by \CFA but |
---|
| 213 | for exceptions only the basic two -- fork and join -- are needed. |
---|
| 214 | |
---|
| 215 | Threads are created like coroutines except the keyword is changed: |
---|
| 216 | \begin{lstlisting} |
---|
| 217 | thread StringWorker { |
---|
| 218 | const char * input; |
---|
| 219 | int result; |
---|
| 220 | }; |
---|
| 221 | |
---|
| 222 | void main(StringWorker & this) { |
---|
| 223 | const char * localCopy = this.input; |
---|
| 224 | // ... do some work, perhaps hashing the string ... |
---|
| 225 | this.result = result; |
---|
| 226 | } |
---|
| 227 | \end{lstlisting} |
---|
| 228 | The main function will start executing after the fork operation and continue |
---|
| 229 | executing until it is finished. If another thread joins with this one it will |
---|
| 230 | wait until main has completed execution. In other words everything the thread |
---|
| 231 | does is between fork and join. |
---|
| 232 | |
---|
| 233 | From the outside this is the creation and destruction of the thread object. |
---|
| 234 | Fork happens after the constructor is run and join happens before the |
---|
| 235 | destructor runs. Join also happens during the \codeCFA{join} function which |
---|
| 236 | can be used to join a thread earlier. If it is used the destructor does not |
---|
| 237 | join as that has already been completed. |
---|