This sounds to me like Java and C/C++ native code can talk to each other
only if they (java and native code) are in the same thread. Is it right, or
in the same process?
Suppose C/C++ native code creates another thread within the shared lib, can
the newly-created thread interact with (call back to) java code? The
newly-created thread should be in the same process as its parent thread and
java code, right?
Thank you.
Lee
-----Original Message-----
From: Nathan Meyers [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 09, 1999 11:52 AM
To: [EMAIL PROTECTED]
Cc: Evandro Luquini; [EMAIL PROTECTED]
Subject: Re: Thread in the Linux's JVM
Jacob Nikom wrote:
>
> 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?
JNI code is just the native "back end" of certain Java methods. It runs
in whatever thread the caller is running in. The only specific issue I
know of is that it's probably easier to hog the CPU in native code than
in Java code.
> 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.
This isn't about thread priorities. In a non-preemptive threading
environment, if one thread is hogging the CPU and never yielding, the
other threads will not get to run regardless of priority. InvokeLater
schedules some code to be run in a different thread (the event
dispatching thread), but doesn't guarantee that that thread will get any
time. You still have to avoid hogging the CPU in all threads.
Nathan
>
> 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$5CBVN2YAAI4VTAMW0
JZE3NUBS1JHEUDO)"
> > > > 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]
----------------------------------------------------------------------
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]
