f2d1091c0f7dbf25fed564695d56253cd68ac04a
[charm.git] / doc / converse / threads.tex
1 \chapter{Threads}
2
3 The calls in this chapter can be used to put together runtime systems
4 for languages that support threads.
5 This threads package, like most thread packages, provides basic
6 functionality for creating threads, destroying threads, yielding, 
7 suspending, and awakening a suspended thread. In
8 addition, it provides facilities whereby you can write your own thread
9 schedulers.  
10
11 \section{Basic Thread Calls}
12
13 \function{typedef struct CthThreadStruct *CthThread;}
14 \index{CthThread}
15 \desc{This is an opaque type defined in {\tt converse.h}.  It represents
16 a first-class thread object.  No information is publicized about the
17 contents of a CthThreadStruct.}
18
19 \function{typedef void (CthVoidFn)();}
20 \index{CthVoidFn}
21 \desc{This is a type defined in {\tt converse.h}.  It represents
22 a function that returns nothing.}
23
24 \function{typedef CthThread (CthThFn)();}
25 \index{CthThFn}
26 \desc{This is a type defined in {\tt converse.h}.  It represents
27 a function that returns a CthThread.}
28
29 \function{CthThread CthSelf()}
30 \index{CthSelf}
31 \desc{Returns the currently-executing thread.  Note: even the initial
32 flow of control that inherently existed when the program began
33 executing {\tt main} counts as a thread.  You may retrieve that thread
34 object using {\tt CthSelf} and use it like any other.}
35
36 \function{CthThread CthCreate(CthVoidFn fn, void *arg, int size)}
37 \index{CthCreate}
38 \desc{Creates a new thread object.  The thread is not given control
39 yet.  To make the thread execute, you must push it into the
40 scheduler queue, using CthAwaken below.  When (and if) the thread
41 eventually receives control, it will begin executing the specified
42 function {\tt fn} with the specified argument.  The {\tt size}
43 parameter specifies the stack size in bytes, 0 means use the default
44 size.  Caution: almost all threads are created with CthCreate, but not
45 all.  In particular, the one initial thread of control that came into
46 existence when your program was first {\tt exec}'d was not created
47 with {\tt CthCreate}, but it can be retrieved (say, by calling {\tt
48 CthSelf} in {\tt main}), and it can be used like any other {\tt
49 CthThread}.}
50
51 \function{void CthFree(CthThread t)}
52 \index{CthFree}
53 \desc{Frees thread {\tt t}.  You may ONLY free the
54 currently-executing thread (yes, this sounds strange, it's
55 historical).  Naturally, the free will actually be postponed until the
56 thread suspends.  To terminate itself, a thread calls
57 {\tt CthFree(CthSelf())}, then gives up control to another thread.}
58
59 \function{void CthSuspend()}
60 \index{CthSuspend}
61 \desc{Causes the current thread to stop executing.
62 The suspended thread will not start executing again until somebody
63 pushes it into the scheduler queue again, using CthAwaken below.  Control
64 transfers to the next task in the scheduler queue.}
65
66 \function{void CthAwaken(CthThread t)}
67 \index{CthAwaken}
68 \desc{Pushes a thread into the scheduler queue.  Caution: a thread
69 must only be in the queue once.  Pushing it in twice is a crashable
70 error.}
71
72 \function{void CthYield()}
73 \index{CthYield}
74 \desc{This function is part of the scheduler-interface.  It simply
75 executes {\tt \{ CthAwaken(CthSelf()); CthSuspend(); \} }.  This combination
76 gives up control temporarily, but ensures that control will eventually
77 return.}
78
79 \function{CthThread CthGetNext(CthThread t)}
80 \index{CthGetNext}
81 \desc{Each thread contains space for the user to store a ``next'' field (the
82 functions listed here pay no attention to the contents of this field).
83 This field is typically used by the implementors of mutexes, condition
84 variables, and other synchronization abstractions to link threads
85 together into queues.  This function returns the contents of the next field.}
86
87 \function{void CthSetNext(CthThread t, CthThread next)}
88 \index{CthGetNext}
89 \desc{Each thread contains space for the user to store a ``next'' field (the
90 functions listed here pay no attention to the contents of this field).
91 This field is typically used by the implementors of mutexes, condition
92 variables, and other synchronization abstractions to link threads
93 together into queues.  This function sets the contents of the next field.}
94
95 \section{Thread Scheduling and Blocking Restrictions}
96
97 Converse threads use a scheduler queue, like any other threads
98 package.  We chose to use the same queue as the one used for Converse
99 messages (see section \ref{schedqueue}).  Because of this, thread
100 context-switching will not work unless there is a thread polling for
101 messages.  A rule of thumb, with Converse, it is best to have a thread
102 polling for messages at all times.  In Converse's normal mode (see
103 section \ref{initial}), this happens automatically.  However, in
104 user-calls-scheduler mode, you must be aware of it.
105
106 There is a second caution associated with this design.  There is a
107 thread polling for messages (even in normal mode, it's just hidden in
108 normal mode).  The continuation of your computation depends on that
109 thread --- you must not block it.  In particular, you must not call
110 blocking operations in these places:
111
112 \begin{itemize}
113
114 \item{In the code of a Converse handler (see sections \ref{handler1}
115 and \ref{handler2}).}
116
117 \item{In the code of the Converse start-function (see section
118 \ref{initial}).}
119
120 \end{itemize}
121
122 These restrictions are usually easy to avoid.  For example, if you
123 wanted to use a blocking operation inside a Converse handler, you
124 would restructure the code so that the handler just creates a new
125 thread and returns.  The newly-created thread would then do the work
126 that the handler originally did.
127
128 \section{Thread Scheduling Hooks}
129
130 Normally, when you CthAwaken a thread, it goes into the primary
131 ready-queue: namely, the main Converse queue described in section
132 \ref{schedqueue}.  However, it is possible to hook a thread to make
133 it go into a different ready-queue.  That queue doesn't have to be
134 priority-queue: it could be FIFO, or LIFO, or in fact it could handle
135 its threads in any complicated order you desire.  This is a powerful
136 way to implement your own scheduling policies for threads.
137
138 To achieve this, you must first implement a new kind of ready-queue.
139 You must implement a function that inserts threads into this queue.
140 The function must have this prototype:
141
142 {\bf void awakenfn(CthThread t);}
143
144 When a thread suspends, it must choose a new thread to transfer control
145 to.  You must implement a function that makes the decision: which thread
146 should the current thread transfer to.  This function must have this
147 prototype:
148
149 {\bf CthThread choosefn();}
150
151 Typically, the choosefn would choose a thread from your ready-queue.
152 Alternately, it might choose to always transfer control to a central
153 scheduling thread.
154
155 You then configure individual threads to actually use this new
156 ready-queue.  This is done using CthSetStrategy:
157
158 \function{void CthSetStrategy(CthThread t, CthVoidFn awakenfn, CthThFn choosefn)}
159 \index{CthSetStrategy}
160 \desc{Causes the thread to use the specified \param{awakefn} whenever
161 you CthAwaken it, and the specified \param{choosefn} whenever you
162 CthSuspend it.}
163
164 CthSetStrategy alters the behavior of CthSuspend and CthAwaken.
165 Normally, when a thread is awakened with CthAwaken, it gets inserted
166 into the main ready-queue.  Setting the thread's {\tt awakenfn} will
167 cause the thread to be inserted into your ready-queue instead.
168 Similarly, when a thread suspends using CthSuspend, it normally
169 transfers control to some thread in the main ready-queue.  Setting the
170 thread's {\tt choosefn} will cause it to transfer control to a thread
171 chosen by your {\tt choosefn} instead.
172
173 You may reset a thread to its normal behavior using CthSetStrategyDefault:
174
175 \function{void CthSetStrategyDefault(CthThread t)}
176 \index{CthSetStrategyDefault}
177 \desc{Restores the value of \param{awakefn} and \param{choosefn} to
178 their default values.  This implies that the next time you CthAwaken
179 the specified thread, it will be inserted into the normal ready-queue.}
180
181 Keep in mind that this only resolves the issue of how threads get into
182 your ready-queue, and how those threads suspend.  To actually make
183 everything ``work out'' requires additional planning: you have to make
184 sure that control gets transferred to everywhere it needs to go.
185
186 Scheduling threads may need to use this function as well:
187
188 \function{void CthResume(CthThread t)}
189 \index{CthResume}
190 \desc{Immediately transfers control to thread {\tt t}.  This routine is
191 primarily intended for people who are implementing schedulers, not for
192 end-users.  End-users should probably call {\tt CthSuspend} or {\tt
193 CthAwaken} (see below).  Likewise, programmers implementing locks,
194 barriers, and other synchronization devices should also probably rely
195 on {\tt CthSuspend} and {\tt CthAwaken}.}
196
197 A final caution about the {\tt choosefn}: it may only return a thread
198 that wants the CPU, eg, a thread that has been awakened using the {\tt
199 awakefn}.  If no such thread exists, if the {\tt choosefn} cannot
200 return an awakened thread, then it must not return at all: instead, it
201 must wait until, by means of some pending IO event, a thread becomes
202 awakened (pending events could be asynchonous disk reads, networked
203 message receptions, signal handlers, etc).  For this reason, many
204 schedulers perform the task of polling the IO devices as a side
205 effect.  If handling the IO event causes a thread to be awakened, then
206 the choosefn may return that thread.  If no pending events exist, then
207 all threads will remain permanently blocked, the program is therefore
208 done, and the {\tt choosefn} should call {\tt exit}.
209
210 There is one minor exception to the rule stated above (``the scheduler
211 may not resume a thread unless it has been declared that the thread
212 wants the CPU using the {\tt awakefn}'').  If a thread {\tt t} is part
213 of the scheduling module, it is permitted for the scheduling module to
214 resume {\tt t} whenever it so desires: presumably, the scheduling
215 module knows when its threads want the CPU.
216
217 \internal{
218 \function{void CthSetVar(CthThread t, void **var, void *val)}
219 \desc{Specifies that the global variable pointed to by {\tt
220 var} should be set to value {\tt val} whenever thread {\tt t} is
221 executing.  {\tt var} should be of type {\tt void *}, or at least
222 should be coercible to a {\tt void *}.  This can be used to associate
223 thread-private data with thread {\tt t}.
224
225 it is intended that this function be used as follows:}
226
227 \begin{verbatim}
228     /* User defines a struct th_info containing all the thread-private  */
229     /* data he wishes to associate with threads.  He also defines       */
230     /* a global variable 'current_thread_info' which will always hold   */
231     /* the th_info of the currently-executing thread.                   */
232     struct th_info { ... } *current_thread_info;
233
234     /* User creates a thread 't', and allocates a block of memory       */
235     /* 'tinfo' to hold the thread's private data.  User tells the       */
236     /* system that whenever thread 't' is running, the global variable  */
237     /* 'current_thread_info' should be set to 'tinfo'.  Thus, thread    */
238     /* 't' can access its private data just by dereferencing            */
239     /* 'current_thread_info'.                                           */
240     t = CthCreate( ... );
241     tinfo = (struct th_info *)malloc(sizeof(struct th_info));
242     CthSetVar(t, &current_thread_info, tinfo);
243 \end{verbatim}
244
245 \desc{Note: you can use CthSetVar multiple times on a thread, thereby
246 attaching multiple data items to it.  However, each data item slows
247 down context-switch to that thread by a tiny amount.  Therefore, a
248 module should ideally attach no more than one data item to a thread.
249 We allow multiple data items to be attached so that independent
250 modules can attach data to a thread without interfering with each
251 other.}
252
253 \function{void *CthGetVar(CthThread t, void **var)}
254 \desc{This makes it possible to retrieve values previously stored with
255 {\tt CthSetVar} when {\tt t} is {\it not} executing.  Returns the value
256 that {\tt var} will be set to when {\tt t} is running.}
257 }