Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA19610; Fri, 12 Jan 96 11:23:34 EST
Received: from liquor.cabi.net by MIT.EDU with SMTP
	id AA24967; Fri, 12 Jan 96 11:23:29 EST
Received: (from listadm@localhost) by liquor.cabi.net (8.6.12/8.6.12) id LAA03019; Fri, 12 Jan 1996 11:23:16 -0500
Resent-Date: Fri, 12 Jan 1996 11:23:16 -0500
From: cjs@netcom.com (cjs)
Message-Id: <199601121621.IAA05655@netcom20.netcom.com>
Subject: Re: Threads and time quantum
To: jsigler@spdmail.spd.dsccc.com (John Sigler)
Date: Fri, 12 Jan 1996 08:21:53 -0800 (PST)
Cc: chapman@u.washington.edu, java-linux@java.blackdown.org
In-Reply-To: <9601121457.AA01598@sun1225.spd.dsccc.com> from "John Sigler" at Jan 12, 96 08:57:10 am
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length:       1825
Resent-Message-Id: <"79Bdq2.0.Pk.9hezm"@liquor>
Resent-From: java-linux@java.blackdown.org
X-Mailing-List: <java-linux@java.blackdown.org> archive/latest/933
X-Loop: java-linux@java.blackdown.org
Precedence: list
Resent-Sender: java-linux-request@java.blackdown.org

> On January 11, Randy Chapman wrote:
> 
> > On Linux, as on Solaris (and on the Mac), Java is strictly one process 
> > using a completely user level threading implementation.  This means,
> >
> > ...
> >
> > A simplistic linux kernel-based threads approach, otoh, would have each
> > thread in what, as far as the time-slicer is concerned, is a separate
> > task, thus each thread of the 3threaded app having the same priority
> > as a full single-threaded app.  Needless to say, this would allow some
> > nasty clone/thread bombs in java, hence why I dont like this idea =(

Randy:

There is no reason why the Java interperter couldn't put some limit on
the number of threads running. Creating/cloning threads, as you know,
is done in native stuff, so there is no reason why you couldn't keep a
counter of threads actually work, and return some sort of error code
when it reaches 32 or something sensible.

As alan cox says, there are lots of reasons why the kernel threads are
better then the user mode threads. 1) the threads take advantage of
kernels with SMP support, 2) the kernel threads will keep functioning
even if one thread is blocked doing disk i/o, paging, or some other
function that normally cannot be done in a non-blocking fashion. 3)
kernel mode threads have less context switching overhead then user
mode threads.

> Sorry if this is a bit off the normal topic but I'd really like to be
> clear on this. Linux has only user mode threads currently, right? Is
> someone is working on kernel mode threads, and if so, does anyone know
> the status? Also I thought Solaris had kernel mode threads? The first
> sentence above seems to say otherwise?

Linux's kernel threads appeared sometime in 1.3.x. Now all processes are
actually kernel threads, and the same kernel function creates them all.

Christopher

