[gclist] Fibers v.s. Threads
Thu, 29 Jun 2000 09:41:54 -0600
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 <firstname.lastname@example.org>
To: 'Charles Fiterman' <email@example.com>; <firstname.lastname@example.org>
Sent: Wednesday, June 28, 2000 11:25 AM
Subject: RE: [gclist] Fibers v.s. Threads
> > From: Charles Fiterman [mailto:email@example.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
> 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
> 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.