On Mon, Nov 22, 1999 at 01:07:14PM -0600, [EMAIL PROTECTED] wrote:
> Nathan,
>
> I really appreciate your valuable information. It helps a lot.
>
> Pardon me for one more question - how to check thread status from command
> line (like "ps" is used to check process status from command line) on Linux?
> I'm new in Linux.
Linux isn't very helpful here. Threads look like processes (technically,
they are processes, albeit lightweight ones)... each has its own PID and
they show up as separate entries in the ps listing. There's no absolute,
rock-solid way to tell them apart, although there are some strong hints:
- If you run ps with the "v" option, such as "ps avx", you'll notice
that all of the threads have exactly the same memory size. That's a
strong hint that they *are* threads sharing the same memory.
- The Linux /proc filesystem gives you a way to look at a process'
memory map. If, for a given two processes, you look at /proc/<pid>/maps
(where <pid> is the process number) and you see identical contents,
that's a strong hint that the two processes are related threads.
If there is a way to get Linux to tell you, absolutely, in no uncertain
terms, that two PIDs belong to related threads, I haven't found it. When
you read up on the __clone() call, you see that (on Linux) the difference
between spawning a process and spawning a thread is a very small matter
of setting a few flags and, AFAIK, Linux will not tell you which flag
values a particular process was started with.
So the bottom line is that you use the same tools (ps and such) to look
at threads that you use for processes, and make an educated (but fairly
easy) guess as to which processes are really related threads.
Nathan
>
> Regards,
>
>
> Lee
>
> -----Original Message-----
> From: Nathan Meyers [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 19, 1999 4:36 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Thread in the Linux's JVM
>
>
> On Fri, Nov 19, 1999 at 03:54:42PM -0600, [EMAIL PROTECTED] wrote:
> >
> > [Nathan]
> > The JVM is a multi-threaded native application. Most of the time it's
> > running native code that implements an interpreter, but some of the time
> > it's running native code that doesn't happen to be in the interpreter
> > (such as JNI methods or JIT-compiled code)....
> >
> > [Lee]
> > {
> > This is a great comment! I didn't pay attention to the
> > simple but important fact - "The JVM is a multi-threaded
> > native application". Can we say that when java calls a native
> > method, what really happens is JVM, the native application,
> > loads a shared lib into its (JVM's) memory space and invokes
> > one of the shared lib's methods. Therefore, no new thread is
> > created at the time when java calls a native method. Is it
> > right or I miss something again here?
>
> You got it! The shared library is loaded into the JVM's shared library
> address space when Java executes the System.loadLibrary() call.
>
>
> > [Lee]
> > If it's true, then why you say "When Java creates a native
> > thread" below? Is a new thread really created when java calls
> > a native method, and how?
>
> No. A new thread is created when Java code invokes Thread.start().
> It's an explicit operation, and certainly not something that just
> happens when you jump between Java and native code.
>
> Native code can also create new threads with pthread_create(), but
> they need to "attach" to the Java JVM so the JVM knows about them.
>
>
> > [Nathan]
> > The important thing is that both the JVM and your native code use the
> > same threading mechanism. Since you're using pthread_create() to create
> > threads, you need to run a version of the JVM (native) that uses the
> > same system. AFAIK, there's no way for JNI code to create new threads
> > in a green thread environment.
> >
> > [Lee]
> > {
> > They uses the same threading mechanism or the same thread?
> > }
>
> Same *mechanism*. When you run with native threads, you run a version of
> the JVM that creates its threads with pthread_create() - just like your
> native code is doing. When you run with green threads, you're running
> with a threading emulation library from Sun that has its own API, isn't
> accessible from your native code, and will tend to crash and burn if
> someone in the process space creates threads with pthread_create().
>
> The thing to understand about green threads is that they were Sun's way
> of getting Java onto a lot of platforms before those platforms had good
> native threading mechanisms. Even today, as the Blackdown team struggles
> with Linux's threading quirks, the green-threaded version of the JVM
> tends to be more reliable. Green threads have their own interesting
> "features": they're not preemptive, and they're not available to native
> code that wants to create or manage threads. But they work.
>
>
> > [Nathan]
> > At any rate, all threads (native or green) are running "in the same
> > process". With native threads, however, different threads have their
> > own PIDs and entries in the process table, which results in confusing
> > "ps" results. (Which is why I put "in the same process" in quotes - if
> > you define a "process" as something with its own PID, then the threads
> > are processes... but they *are* lightweight processes!)
> >
> > [Lee]
> > {
> > http://pauillac.inria.fr/~xleroy/linuxthreads/README says that
> > threads not sharing parent's pid is a known bug (see "KNOWN BUGS
> > AND LIMITATIONS" section). Is it right?
> >
> > Can you see a new process besides "java" process after java calls
> > a native method? I made a simple jni code, run it and couldn't
> > find extra process besides "java" by using "ps -a". The native
> > method is a infinity loop, so I have time to check ps.
>
> Again, calling JNI methods doesn't create a new thread... calling
> Thread.start() does. That's why you don't see a new thread just by
> calling native code.
>
> The information in that README file is correct; it happens just as much
> with multi-threaded C++ applications as with Java. But it's a limitation,
> not a bug. This "feature", along with some others (for example, how the
> thread stacks are laid out in the address space), makes it difficult to
> create a multi-threaded application with more than a few hundred threads.
>
> Now, applications with hundreds of threads are arguably employing Bad
> Programming Practice, but there are developers who will defend to the
> death their right to create such applications and who consider the
> per-thread use of precious resources (slots in the process table) to be
> a bug.
>
> But it isn't a bug. There's no spec that says threads have to share the
> same PID. Ignoring this quirk, Linux threads are true threads: they run
> in a common process space, and the cost of context-switching between
> them is lower than the cost of context-switching between heavyweight
> processes.
>
> Nathan
>
>
> ----------------------------------------------------------------------
> 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]
