Pre-emptive or co-operative concurrency (was: Concurrency)
Claus Reinke
claus.reinke at talk21.com
Wed Mar 29 11:21:17 EST 2006
> Pre-emption means that (1) threads have priority levels, and (2) that a
> higher priority thread can steal the processor from a currently-running
> lower priority thread, and (3) it can do so "immediately" it needs to,
> without waiting for some "safe" synchronisation point.
obviously, cs-concepts are still taught differently around the globe..
I was taught that non-preemptive scheduling simply means that threads
will never be preempted, so they complete whatever they want to do,
then voluntarily return control. the opposite, preemptive scheduling,
allocates schedule resources to threads independent of their needs,
solely based on meta-level properties (time slices, number of
reductions, ..), so threads may be preempted by a context switch
in whatever they are doing.
there is no implication of priorities, nor is there an implication of
re-scheduling not happening at "safe" synchronisation points. it is
just that "safety" is from the scheduler's point of view (a reduction
step has completed), not from the thread's point of view (all the
steps needed for a certain task have been completed).
so (at least in my background;-), non-preemptive scheduling implies
cooperative concurrency (if any of the threads does not play fair
with yields, the whole scheduling arrangement may break down),
and preemptive scheduling implies careful programming for another
reason (none of the threads may assume that it won't be interrupted
and resumed in the middle of some complex activity; which is why
atomic actions, transactions, STM, and the like are so important).
all of the concurrency implementations discussed so far seem to
be based on a mixture of preemptive and non-premptive scheduling.
context-switches happen only on specific events, which every
thread will usually engage in, although it need not always do so:
1 only calls to yield
2 any calls to concurrency library api
3 any allocation
these differ merely in the level of cooperation required from
threads in order to achieve the appearance of pre-emptive
scheduling. each of them can be defeated by non-cooperative
thread code, so none of them is entirely preemptive. however,
the more possible thread events are permitted as context-switch
points, the closer we come to a preemptive scheduler, as there
is less and less potential for threads to be non-cooperative.
cheers,
claus
More information about the Haskell-prime
mailing list