The JNI/C code DOES execute in the same thread as the Java thread that
invokes it. You must consider this in your design. Also, you can't
have a "non-Java" thread perform a call-back to a Java object.
Brett Smith
Subject:
Re: Thread in the Linux's JVM
Date:
Tue, 09 Nov 1999 12:23:35 -0500
From:
Jacob Nikom <[EMAIL PROTECTED]>
To:
Nathan Meyers <[EMAIL PROTECTED]>
CC:
Evandro Luquini <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
So, you think that JNI does not represent any specific issues in
Java multithreading? Does the JNI/C code executes in the same thread
as the Java method which invoked it?
Also, what about event-dispatching thread? In the documentation about
InvokeLater() method there is no any mention that you have to change
the non-event-dispatching thread's priority in order to allow the
event-dispatching thread get called. Is it simply assumed? This is
strange.
Jacob Nikom
Nathan Meyers wrote:
>
> Jacob Nikom wrote:
>
> > It would be nice to know more about multithreading features of Linux
> > JVM.
>
> There are two threading models. If you run with green threads, there
is
> no preemption, and control passes between threads either with yield()
> calls or possibly with other calls that can block (such as sleep() and
> various I/O calls).
>
> If you run with native threads, the JVM is using the system's pthread
> API, which (except for very strangely configured systems) means it's
> using kernel threads. They give you preemption but not thread
> priorities, and there is no guarantee about the size of the time
slices,
> when preemption occurs, or how thread execution is distributed across
> multiple processors.
>
> It sounds from your description like you're relying on preemption.
> Unfortunately, that's a bad thing - Java doesn't guarantee that you'll
> get it, and you need to code as if preemption will not happen.
> SwingWorker is a nice tool for conveniently launching another thread,
> but it doesn't magically turn non-preemptive threads into preemptive
> threads.
>
> So to your problem... why did the behavior change when you rewrote
some
> of your Java methods as native methods? My guess is that you were
using
> some Java methods that do voluntary yields, and you stopped using them
> when you rewrote the code as native methods.
>
> BTW, that Sun article mentioned in Evandro's original mail (below)
> discusses why Solaris is a good platform for applications that rely on
> preemptive multi-threading. But it's a Solaris marketing article, not
a
> Java programming guide. The Java portability message is very clear:
> don't rely on preemption.
>
> Nathan
>
> >
> > Hi,
> >
> > Thank you for bringing up this question. I also have problems with
> > multiple threads in Linux. In my case the behavior of threads with
> > JNI is different from pure Java behavior.
> >
> > I use SwingWorker class. If I don't have JNI methods I don't have
> > to use yield() method. If I replace my Java methods with JNI calls
> > I must use yield(), otherwise the application simply does not work.
> > There is no mentioning of yield() method in any SwingWorker-related
> > documentation.
> >
> > It would be nice to know more about multithreading features of Linux
> > JVM.
> >
> > Jacob Nikom
> >
> > > Evandro Luquini wrote:
> > >
> > > Hi,
> > > In the JavaWord article called "programming Java threads in the
real
> > > world, Part 1(
> > > http://www.javaworld.com/jw-09-1998/jw-09-threads.html)", the
author
> > > sad that "Java's promise of platform independence falls flat on
its
> > > face in the threads arena". If you read this paper you will can
see
> > > two plataform example : NT and Solaris.
> > >
> > > Major question is what scheduling is implemented by the Linux JVM
and
> > > the Linux OS. Does it use a nonpreemptive our preemptive scheduler
?
> > >
> > > The other important question is about what thread's architecture
is
> > > implement by Linux O.S. I am asking it because in the sun's paper
> > > "Multithreading: General And Java-Specific Information
> > >
(http://www.sun.com/solaris/java/wp-java/4.html;$sessionid$5CBVN2YAAI4VTAMW0JZE3NUBS1JHEUDO)"
> > > sad : "Understanding the architectural advantages of one native MT
> > > environment/architecture over another is critical to an
understanding
> > > of the advantages of one Java implementation over another. Since a
> > > typical JVM runtime is implemented on top of the traditional
platform,
> > > a richer, architecturally superior MT platform will obviously
> > > translate to a superior Java MT environment for Java applications
on
> > > that platform. The native OS threads model greatly influences Java
> > > application performance."
> > >
> > > Thanks
> >
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
