are green threads et al really cheaper ? 
Author Message
 are green threads et al really cheaper ?

Hi,

an often cited advantage of user-level thread implementations vs. 'native'
threads in language runtimes like Java or Smalltalk is that these 'green'
threads are much cheaper, i.e. faster to create, synchronize and take
away less resources.

I wonder, does this apply to modern, two-level pthread implementations
like the ones found in D-UNIX, Solaris, IRIX, ... ? These do much of the  
work in user-level, too, so I expect they should be as cheap.

So, does it still make sense to implement user level threading systems
(disregarding portability, scheduling control, ...) ?

Regards
  Matthias

--
Face it: [...] Java marries the disadvantages of C++-style strong
static typing with the disadvantages of Smalltalk-style typelessness.
(comp.lang.beta)



Wed, 18 Jun 1902 08:00:00 GMT  
 are green threads et al really cheaper ?

Quote:

> Hi,

> an often cited advantage of user-level thread implementations vs. 'native'
> threads in language runtimes like Java or Smalltalk is that these 'green'
> threads are much cheaper, i.e. faster to create, synchronize and take
> away less resources.

May have been true on older, non-threaded OSs.
Quote:

> I wonder, does this apply to modern, two-level pthread implementations
> like the ones found in D-UNIX, Solaris, IRIX, ... ? These do much of the
> work in user-level, too, so I expect they should be as cheap.

> So, does it still make sense to implement user level threading systems
> (disregarding portability, scheduling control, ...) ?

I'd say no, if the OS is threaded, you will be hard pushed to do better
for any but the most simple cases.

        Ian Collins.



Wed, 18 Jun 1902 08:00:00 GMT  
 are green threads et al really cheaper ?

[snip]

Quote:

> I'd say no, if the OS is threaded, you will be hard pushed to do better
> for any but the most simple cases.

>         Ian Collins.

Agreed.

--
/**
 * Robert Garskof - Software Developer
 * Southern New England Telephone (SNET)

 * Web Page : http://www.snet.com
 */



Wed, 18 Jun 1902 08:00:00 GMT  
 are green threads et al really cheaper ?

Quote:
>I'd say no, if the OS is threaded, you will be hard pushed to do better
>for any but the most simple cases.

My experiences go the other way.  I find user level threading to
be more efficient on single processors. But to take advantage
of a multiprocessor or native code os access I would prefer
OS threading.

Chris



Wed, 18 Jun 1902 08:00:00 GMT  
 are green threads et al really cheaper ?

Quote:

>>I'd say no, if the OS is threaded, you will be hard pushed to do better
>>for any but the most simple cases.

>My experiences go the other way.  I find user level threading to
>be more efficient on single processors. But to take advantage
>of a multiprocessor or native code os access I would prefer
>OS threading.

It really depends on the JVM, and how it implements threads. If it
implements threads via a linked in library, and does not create a
peer-thread in the kernel, then the thread will be invisible to the OS.

For example...

Assume the JVM doesn't support kernel threads. On your machine (single
processor or multiple processor), you have two Java processes.

The first has 10 threads, the second has 2.

Assuming your OS is multiprocessing, then it will give CPU time to each
process. Because the OS can't see the threads in the processes, it gives
each process equal CPU time.

The first process has 10 threads, and gets 50% of the CPU time, and thus
each thread gets 5% of the CPU cycles.

The second process has 2 threads, and gets 50% of the CPU time, and thus
each thread gets 25% of the CPU cycles.

Hardly fair.

Now switch to a JVM that implements threads as kernel threads.

Now the OS sees the 12 threads (as opposed to 2 processes). It can give each
thread about 8% of the CPU cycles. Thus the process with 10 threads gets a
bigger share of the CPU time, as it has more work going on.

To sum up, you are constrained by more than just the OS and the # of
processes. The JVM will determine how your threads are handled.



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Henry et al (really BSI proposed) I/O library

2. Global interpreter locks, thread states et al...

3. clipper 87- i am cheap- is force cheap?

4. clipper 87- i am cheap- is force cheap?

5. Tabbing between controls et al.

6. AFP MO:DCA OGL ACIF et al conversion to HTML

7. Newsreader, c.l.a Archive, et al.

8. EVENT:timer ......CW2.003 et.al ..... WINDOWS Template

9. Trees et-al

10. Y2K : for Mel, Anne, Phil et.al

11. good link to read as we contemplate RAA, RAA.succ, et al

12. Rotate, et al

 

 
Powered by phpBB® Forum Software