On 23 Sep 1998 00:31:35 -0700, Anand Palaniswamy wrote:
>> An alternative is Kaffe, but it's too incomplete to be usable right now.
>> Is anyone working on producing a version of the JDK that uses native
>> threads ?
I don't know if Kaffe actually uses native threads... Since Native
Threads do not exist on FreeBSD, it for sure does not use them there...
>> I remember reading about some "problems" with this. What are the problems?
>
>The basic problem is that POSIX threads (the API implemented by
>LinuxThreads) doesn't have suspend and resume primitives. These are
>required because:
> - Of the need to support the java.lang.Thread.suspend() and resume()
> methods (these 2 have been deprecated in 1.2).
> - Sun's implementation starting a new thread suspended.
> - You need to suspend other threads during garbage collection.
Well, these are interesting issues, but most of them can be handled
with some thought. An OS-Layer I designed at Scala was to have threads
much like Java does (and it is object based too...) Anyway, the goal
was to be able to port this OS to run on top of other operating systems
or to be its own operating system.
We also have much the same threading features, including the creation of
a thread in "suspended" state. Now, on some platforms this actually means
starting the thread but hiding that fact by having our code then wait for
a message/signal to continue before it jumps to the user level code.
The suspend feature is tricky but we never defined how quickly it would
suspend a thread. The reason we did not define this is because of multi-
processor environments where the suspend call may be running at the same
time as the thread that is being asked to be suspended. Thus it could
not be used for synchronization. We delt with that by having the method
calls notice the suspend and not continue until resumed. (Yes, in the
method call interface, so there is some extra overhead to a method call
if the underlying OS does not support the behavior)
We did not have garbage collection, but that can also be handled in
much the same way.
However, this does bring up the performance issues. Given how the Linux
threading model is designed, you will run complex multi-threaded code
noticeably slower on single processor systems and maybe even with
multi-processor systems, depending on what the code does. There is
significant overhead to doing things like GC and monitor locking that
could end up using enough extra resources that it becomes a net loss.
(Now, the OS/2 threading model, for example, would be a very good match
to the Java threading model. The Amiga "tasks" fit even better, but
that does not help Linux...)
>Note to friends of LinuxThreads:
>
> LinuxThreads FAQ indicates that one workaround is to post SIGSTOP and
> SIGCONT signals and these are akin to suspend/resume. However, I
> noticed that if a process flags has PF_PTRACED, the SIGSTOP isn't
> really delivered, meaning I can't run the VM under gdb -- which makes
> this option useless. I'll have to find an alternative solution for
> suspend/resume.
>
> LinuxThreads uses SIGUSR1 and SIGUSR2, so it is not so embeddable.
> Don't get me wrong -- I like LinuxThreads, I was impressed by the
> cleanliness of its implementation, and it just works, but threads the
> kernel really understood would be nice.
Yes, they were nicely patched into the system, but a real threading model
would be much better. Also, it would be nice if the number of threads
were not hard limited. There is no excuse in today's world to have fixed
tables for processes or threads. Someone should maybe look at how the
Amiga handled "tasks" for an example of "unlimited" numbers of tasks with
minimal to no impact on performance.
>-Anand
>
>[1] Two caveats:
> - compute bound threads can starve other threads. But there is a
> un-supported -ts flag that makes the green threads VM time slice.
There is nothing that says that a green-threads implementation may not
timeslice anyway. The Java spec says that it does not have to, mainly
so that Java can be made to run to spec on a large number of systems.
> - native methods can short-circuit the wrappers and block. Native
> methods in the JDK don't do this.
This is an issue. JNI code should make sure it links with the green
threads wrappers so that all of the blocking calls are handled correctly.
(Or at least all of the blocking calls that it happens to have wrappers
for)
> Also System.in.read() is known to block the entire process on
> Solaris green threads atleast (fixed in 1.2).
The Linux port has this fixed now. The Solaris green threads version has
this broken since they do not change the file descriptors for the STDIN/
STDOUT/STDERR to non-blocking file descriptors. This was done due to a
problem outside the control of the Java group (the shell would get confused)
but this has been addressed in Solaris (and is not an issue in Linux)
Plus, with native threads this is (or should not be) an issue.
Also native threads still have issues with blocking calls and monitor locks.
Michael Sinz -- Director of Research & Development, NextBus Inc.
mailto:[EMAIL PROTECTED] --------- http://www.nextbus.com
My place on the web ---> http://www.users.fast.net/~michael_sinz
