[gclist] Fibers v.s. Threads

[Greg Colvin]

The Oracle Java VM provides only non-preemptive threads,
as is allowed by the language spec.  So far as I know
it hasn't been a problem for our customers.

----- Original Message ----- 
From: Boehm, Hans <hans_boehm@hp.com>
To: 'Charles Fiterman' <cef@geodesic.com>; <gclist@iecc.com>
Sent: Wednesday, June 28, 2000 11:25 AM
Subject: RE: [gclist] Fibers v.s. Threads


> > 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
>