Quoting Benjamin Scott <[EMAIL PROTECTED]>:
> > Java is inherently multi-threaded and when using native threads (a must
> on
> > multi-CPUs and on production JVMs from Sun) it inherits the threading
> > model of the OS it runs on.  The "every thread is a process" model
> doesn't
> > seem to scale under big time loads running multi-threaded apps.
>   I don't agree.  Fundamentally, there does not have to be any difference
> between a thread and a process.  Indeed, threads are often called
> "lightweight
> processes".  Because threads can share resources like file descriptors and
> memory space, people sometimes think of them as something radically
> different
> then regular processes.  But they're not.  Read on.

  While not that different, I'd say it's comparable to a Beagle vs a Pit Bull. 
Same thing, a dog, but they don't look alike, sound alike, or, in many cases,
behave alike.

> > Two major problems are the algorithms used by the kernel scheduler, which
> > wastes lots of time scheduling all these individual processes...
>   Um, *something* is going to have to schedule those threads.  If it isn't
> the
> process scheduler, it is going to be some other code, be it a separate
> kernel
> thread scheduler or a userland thread library.  You can't make that
> scheduling
> overhead go away simply by moving it out of the kernel.  :)

  Yes, but you have different issues.  An example usage of different thread
implementations would be the pth library.  This is a userland threading library,
that does not use kernel threads themselves.  Using it, I can easily handle
30,000 threads of execution, without a hitch.  Now, 30,000 kernel threads,
well..  Let's just say ps -ax would be rather lengthy, as soon as the OS got
around to actually running it.

> > and the related problem of a lack of a user-level threads library.
>   It has been noted that *working* with Linux threads is not as easy as it
> could be.  But I imagine a library to handle the messy details for you
> isn't
> that far off.

  It's not working with pthreads that's an issue, IMHO, it's the overall weight
(overhead) that the threads require.  Perhaps it's the scheduler, I, not that
sure, but the fact of the matter is, kernel threads require a whole lot more
overhead then they need to.

--- 
Thomas Charron
<< Wanted: One decent sig >>
<< Preferably litle used  >>
<< and stored in garage.  ?>>

**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************

Reply via email to