[gclist] Fibers v.s. Threads

[Bob Kerns]

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.

-----Original Message-----
From: Greg Colvin [mailto:gcolvin@us.oracle.com]
Sent: Thursday, June 29, 2000 08:42
To: Boehm, Hans; 'Charles Fiterman'; gclist@iecc.com
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 <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
>