[gclist] Fibers v.s. Threads

[Boehm, Hans]

> From: Charles Fiterman [mailto:cef@geodesic.com]
> 
> The basic difference between a fiber and a thread is a thread 
> can switch
> control at any time while a fiber must explicitly give up control.
> 
> In the world of displays and human interaction threads rule. 
> In the world
> of machine control and mechanical interaction fibers rule. 
> The difference
> is that with threads you never know when you might lose 
> control and every
> sequence is in danger. With machine control this is simply 
> too much danger.
> 
> Scheme etc. with continuations gives fiber type behavior to high level
> languages but it never caught on.
> 
Is it the application domain or the system complexity that makes the
difference?  I have limited experience with non-preemptive systems, but have
always found them to be very difficult to deal with, for a number of
reasons:

1) If you rely on nonpreemption, you have to be aware of exactly which calls
can potentially yield.  Most forms of output can potentially block.  If I/O
doesn't yield, you can't do anything while you're waiting.  If it does, then
inserting a debugging printf potentially breaks your code.

2) You can't rely on nonpreemption on a multiprocessor.  Thus these systems
break when you try to move them to a multiprocessor, and the breakage is
very hard to repair.

3) In a nonpreemptive system, a background computation has to explicitly
yield inside every potentially unbounded loop.  This means you can't really
use standard library code, and you need to uglify all code used in such a
computation.

My impression is that various PC operating systems started with mostly
nonpreemptive models (Novell, Windows, Apple), and have been trying to get
away from it.

The original Sun JVMs could preempt threads if a higher priority thread
became runnable, but were not time-sliced.  Solaris threads shared (do they
still) the same model.  There are easy workarounds to get both of them to
time-slice, but otherwise I found both of them to be painful, both due to
problem (3), and because they tend to obscure, but not eliminate,
synchronization bugs.  I believe the Pthreads standard also allows this
behavior.  I don't know about Pthreads on Solaris, but Pthreads on most
other systems are time-sliced.

I'm not sure where Scheme fits.  Are "engines" part of the standard?  If so,
you do get preemptive behavior.

Hans