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 | |
---|
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. |
---|
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 |
---|
97 | does work. The complier will deduce that \codeCFA{do_twice}'s T is an |
---|
98 | integer from the argument. It will then look for a definition matching the |
---|
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 |
---|
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 |
---|
158 | modified by the compiler to satify the \codeCFA{is_coroutine} trait. |
---|
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. |
---|