Lee Chee Wai wrote:
> I have read the README file associated with the 1.1.7b port on
> the native thread support package and am a little confused by the
> description of native and "green" threads.
>
> I'd first like to ask about "green" threads. What exactly are
> they and where can I get more information about them?
Sounds like you know what threads (lightweight processes) are, so I
won't bore you (or the list readership) with any definitions.
When implementing threads -- no matter how you are implementing them --
the goal is to have multiple flows of execution going in the same
address space. The question is who performs the switching between the
threads. The answer is either:
1) The kernel controls it, or
2) It's controlled in user space.
Native threads use answer #1, while green threads are the (nearly)
OS-independent Sun version of answer #2. They have the advantage of
working, with some porting effort, on OSes that don't support threads
well in the kernel and/or in system libraries.
> The second question is about the description of native
> threads. From the README file, it sounds as if native threads are in
> fact UNIX processes instead of pthread lightweight threads (which from
> my understanding are user-level threads that can still be handled by
> the OS in an SMP environment).
This is the part of your question that's Linux-specific (which exempts
you from the customary "this isn't a Linux question" rebuke :-). The
Linux OS supports kernel threads. They are threads in the true sense of
the word: multiple paths of execution operating in a shared address
space, including preemptive thread-switching performed by the kernel.
It so happens that the Linux implementation of threads causes each
thread to take up space in the process table. There are some potentially
unpleasant implications (a fairly low limit on thread count) but they
are otherwise no different from anyone else's notion of threads.
Now about pthreads: that's an API for C programmers, not a threading
mechanism. A multithreaded application might choose to use this API
because it's portable. There's nothing about the pthread API that
commits you to a particular underlying thread implementation -- it might
be a user-space or kernel-space implementation, it might or might not do
preemption, it might or might not clutter up the process table.
> Could you please help clarify my doubts on the above? The JVM
> I've used for Solaris does not seem to exhibit non-deterministic
> behaviour as is expected of simultaneously executing threads even on
> an SMP machine with 4 processors.
The surprises you're hoping for are more likely to happen with a
threading mechanism that does preemption. In general, you're more likely
to see them with a native thread implementation than a green thread
implementation.
Nathan Meyers
[EMAIL PROTECTED]
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
