Bill & Martinah Smith wrote:
>
> I don't believe this is completely true. When using Java on Solaris, we were
> set up to use green threads because it required a bunch of OS patches to use
> java native threads. We ran into performance issues with green threads when
> we would spin off threads to do background work. We finally decided to make
> the OS patches and ran the same application with native threads and the
> performance improvement with native threads was huge. These were single CPU
> workstations. I'm not completely sure of the reasons, but I speculate that
> it had something to do with thread scheduling. Green threads seemed to
> require the application to yield in the active thread in order for another
> thread (of the same priority) to get a chance to run. This, of course, was
> the Solaris version, not the Linux version. :)
Sounds like you had some dependencies on unspecified thread behavior - a
not uncommon problem. Java makes no guarantees about thread preemption.
You're right about the definition not being completely accurate. Native
threads use a local threading API instead of Sun's "green" emulation. In
non-Solaris Unix environments, that API is the Posix pthreads API, which
might itself use kernel mechanisms or might be an emulation. In Linux,
the pthreads libraries do indeed use kernel-supplied threading
mechanisms.
> Are you sure about each thread running in it's own process? If so, this is a
> java only thing, because this isn't the case with normal multithreaded
> applications.
On Linux, individual threads each occupy an entry in the process table
and have their own PID. They aren't full processes, they are true
lightweight threads all sharing the same address space. So depending on
how you define "process" (taking space in the process table vs. running
in an unshared address space), Linux threads do or do not run in their
own process. Their use of process table entries, which you can see when
you run "ps" or "top", results in those occasional panicked questions
about "why does Java take so many processes"?
Nathan
>
> > Like my compadres before me said, native threads run at the
> > OS level, and
> > therefore can access multiple cpus. However, it is my
> > understanding that
> > this is the only time native threads should be used. On
> > single processor
> > systems, green threads are faster, and you aren't limited by
> > any process
> > limitations in the OS. Since in native threads, each thread
> > runs in it's
> > own process, you run the risk of running out of available
> > processes. You
> > don't have that with green threads.
> >
> > though I'm sure there are limitations on green threads as
> > well, I don't
> > know whether or not they are definite or limited only by machine
> > capability.
> >
> > On Fri, 30 Jul 1999, Pere Serra wrote:
> >
> > > I have an easy question:
> > > What's the difference between native threads and green theads?
> > > Which one is more eficient/stable?
> > >
> > >
> > >
> > ----------------------------------------------------------------------
> > > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> > > with a subject of "unsubscribe". Trouble? Contact
> > [EMAIL PROTECTED]
> > >
> >
> >
> > ----------------------------------------------------------------------
> > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> > with a subject of "unsubscribe". Trouble? Contact
> > [EMAIL PROTECTED]
> >
> >
>
> ----------------------------------------------------------------------
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
