[gclist] Fibers v.s. Threads
Thu, 29 Jun 2000 08:57:59 -0700
Thanks for the warning!
We pulled a former (C++) product from the HPUX platform because HPUX did not
then support preemptive threads. True, in HPUX's case, they compounded the
problem by having two versions of libraries, and if a non-threaded one got
called in a thread, the thread would block, but not yield to another thread,
thus hanging all threads. You couldn't control what versions of the system
libraries were used by third-party libraries.
But even without this extra glitch, non-preemptive threads do NOT meet my
definition of threads, and fail to supply the robustness that is one of the
reasons I use threads: the system can continue to function overall, even if
one worker goes CPU-bound for a substantial period of time.
Note that on the Mac and PC, back before preemptive threads, HUGE numbers of
application bugs were simply due to a failure give up control at appropriate
points. Placing this burden on programmers virtually guarenteed that this
would happen -- and continue to happen.
From: Greg Colvin [mailto:email@example.com]
Sent: Thursday, June 29, 2000 08:42
To: Boehm, Hans; 'Charles Fiterman'; firstname.lastname@example.org
Subject: %%: Re: [gclist] Fibers v.s. Threads
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 <email@example.com>
To: 'Charles Fiterman' <firstname.lastname@example.org>; <email@example.com>
Sent: Wednesday, June 28, 2000 11:25 AM
Subject: RE: [gclist] Fibers v.s. Threads
> > From: Charles Fiterman [mailto:firstname.lastname@example.org]
> > 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
> 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
> can potentially yield. Most forms of output can potentially block. If
> doesn't yield, you can't do anything while you're waiting. If it does,
> inserting a debugging printf potentially breaks your code.
> 2) You can't rely on nonpreemption on a multiprocessor. Thus these
> 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
> 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
> 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
> you do get preemptive behavior.