@@ -200,27 +200,26 @@ small number of tests.
200
200
IOSimPOR Scheduling
201
201
-------------------
202
202
203
- IOSimPOR distinguishes between test threads and system threads; test
204
- threads are intended to be part of the test itself, whereas system
205
- threads are part of the system under test. The main thread in a test
206
- is always a test thread; test threads can fork system threads, but not
207
- vice versa. Test threads always take priority over system threads, and
208
- IOSimPOR does not attempt to reverse races involving test threads. So
209
- when writing a test, one can assume that whatever the test threads do
210
- takes place first (at each simulated time point), and then the system
211
- threads run and any races between them are explored. Likewise, if a
212
- blocked test thread responds to an event in a system thread, then the
213
- test thread's response will take place before the system threads
214
- continue execution. Distinguishing test threads from system threads
215
- drastically reduces the set of races that IOSimPOR needs to consider.
216
-
217
- To start a system thread, a test thread may call
203
+ IOSimPOR distinguishes between non-racy threads and system threads; test
204
+ threads are intended to be part of the test itself, whereas system threads are
205
+ part of the system under test. The main thread in a test is always a non-racy
206
+ thread; non-racy threads can fork system threads, but not vice versa. Test
207
+ threads always take priority over system threads, and IOSimPOR does not
208
+ attempt to reverse races involving test threads. So when writing a test, one
209
+ can assume that whatever the test threads do takes place first (at each
210
+ simulated time point), and then the system threads run and any races between
211
+ them are explored. Likewise, if a blocked non-racy thread responds to an event
212
+ in a system thread, then the test thread's response will take place before the
213
+ system threads continue execution. Distinguishing non-racy threads from system
214
+ threads drastically reduces the set of races that IOSimPOR needs to consider.
215
+
216
+ To start a system thread, a non-racy thread may call
218
217
219
218
exploreRaces :: MonadTest m => m ()
220
219
221
220
All threads forked (using forkIO) after such a call will be system
222
221
threads. If there is no call to exploreRaces in a test, then all the
223
- threads forked will be test threads, and IOSimPOR will not reverse any
222
+ threads forked will be non-racy threads, and IOSimPOR will not reverse any
224
223
races---so it is necessary to include a call to exploreRaces somewhere
225
224
in a test.
226
225
@@ -234,7 +233,7 @@ easy to see which thread forked which other, and relatively easy to
234
233
map thread ids in debugging output to threads in the source code.
235
234
236
235
Except when reversing races, IOSimPOR schedules threads using
237
- priorities. Test threads take priority over system threads, but
236
+ priorities. Non-racy threads take priority over system threads, but
238
237
otherwise priorities are determined by the thread ids: the thread with
239
238
the lexicographically greatest thread Id has the highest priority. As
240
239
a result, threads behave in a very predictable manner: newly forked
0 commit comments