• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Does "Java Threads" book discuss OS Platform Dependency issue?

 
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The following is from your reply in that thread

Originally posted by Henry Wong:
The studies cover single threaded, 2 threads, and many threads, for Windows, Linux, and Solaris.



I'm starting a new thread, because I guess the topic is a bit different from that thread...

I just would like to know the book discusses OS platform dependency issue... OR is it just a small part in the chapter-14(Thread Performance)?

Thanks...
 
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
IMO from the point of view of a developer there is no difference on how many threads you use in your code and also on what machine your application will finally run. How JVM will interact with the underlying OS for thread management (native threads, green threads) this is quiete another story .

./pope
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ko Ko Naing:
I just would like to know the book discusses OS platform dependency issue... OR is it just a small part in the chapter-14(Thread Performance)?

Thanks...



Ideally, a threading book on Java should not go into platform specific issues. After all, that is the purpose of Java. However, there were two chapters where this could not be avoided.

First, the already discussed performance chapters. It is not possible to give measurements of performance without actually choosing a configuration. The second chapter is the chapter on schedulling which goes into details on the many schedulling models.

Henry
[ October 21, 2004: Message edited by: Henry Wong ]
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Henry Wong:

First, the already discussed performance chapters. It is not possible to give measurements of performance without actually choosing a configuration. The second chapter is the chapter on schedulling which goes into details on the many schedulling models.



You mean processor task scheduling or something else?

./pope
 
Henry Wong
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ali Pope:

You mean processor task scheduling or something else?

./pope



The schedulling chapter goes into detail on how the Java threading model maps onto the underlying threading model. It goes into detail on behavior, priorities, features, etc. Model discussed includes green threads, Windows, Solaris, and Linux.

Henry
 
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are no platform threading issues for you to be concerned about when you program in Java. Java threads follow the behavior defined in the specification.

Some people are not able to understand the fact that java hides the CPU from the programmer and they get all concerned with underlying OS. Please don't make that mistake.
 
Henry Wong
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by CL Gilbert:
There are no platform threading issues for you to be concerned about when you program in Java. Java threads follow the behavior defined in the specification.

Some people are not able to understand the fact that java hides the CPU from the programmer and they get all concerned with underlying OS. Please don't make that mistake.



Agreed... For the most part, the schedulling chapter will probably be nothing more than an interesting read, with lots of trivia on scheduling.

However, the specification is pretty lax in this area. For those who are using thread priorities to specifically control schedulling, this chapter should provide hints in accomplishing it for their platform.

BTW, in eariler editions of Java Threads, we use to implement a scheduler -- and variants of it -- in the scheduling chapter. In this edition, this section was removed, as it was not possible to guarantee scheduling -- which is probably the main reason why you would want to write your own scheduler.

Henry
 
Ko Ko Naing
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Henry Wong:


The schedulling chapter goes into detail on how the Java threading model maps onto the underlying threading model. It goes into detail on behavior, priorities, features, etc. Model discussed includes green threads, Windows, Solaris, and Linux.

Henry



That chapter seems interesting for me as well... Whenever we talk about scheduling, we usually think about task scheduling... but there are more things to consider, like you said, behavior, priorities, features, etc....

So there are only two chapters that are dealing with Platform-dependent issue... I do thank you very much for your great responses to us here in the Ranch...
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Henry Wong:


The schedulling chapter goes into detail on how the Java threading model maps onto the underlying threading model. It goes into detail on behavior, priorities, features, etc. Model discussed includes green threads, Windows, Solaris, and Linux.

Henry



Henry are the green threads still there in the last versions of JVMs? (I think they are gone since 1.3, ain't it?)

./pope
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by CL Gilbert:
[...]



Sometimes I am interested in seeing the JVM interactions with the underlying OS. Doesn't matter how good your code is if the JVM has issues interoperating with the OS. Happily some of the JVMs (if not almost all) are pretty good at this.

./pope
 
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


There are no platform threading issues for you to be concerned about when you program in Java. Java threads follow the behavior defined in the specification.

Some people are not able to understand the fact that java hides the CPU from the programmer and they get all concerned with underlying OS. Please don't make that mistake.



A big mistake is to believe that by interacting with the thread scheduler through the core API is always going to be platform-dependant.

Here are a couple of pointers:
- look up why double-checked locking doesn't work on multiple CPU machines.
- have a read of "Taming Java Threads, Allen Holub" - a cynical approach towards how Java threads work, pointing out the many mistakes you can make and the mistakes of the existing API.
 
Henry Wong
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

- look up why double-checked locking doesn't work on multiple CPU machines.



I don't think this works for single CPU machines either.

Henry
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Tony Morris:


A big mistake is to believe that by interacting with the thread scheduler through the core API is always going to be platform-dependant.

Here are a couple of pointers:
- look up why double-checked locking doesn't work on multiple CPU machines.
- have a read of "Taming Java Threads, Allen Holub" - a cynical approach towards how Java threads work, pointing out the many mistakes you can make and the mistakes of the existing API.



In those cases where the behavior is not platform independent, the particular JVM you are using is violating the specificaiton. Take up the issue when them.

And as for double checked locking the simple argument is that it is not specified to work. DCL only works where it is specified to work. This is the same thing for C, C++, C# and any other language.
 
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by CL Gilbert:
In those cases where the behavior is not platform independent, the particular JVM you are using is violating the specificaiton. Take up the issue when them.



Rigid indeed...

I disagree but it may be because of our perspectives. If you are speaking strictly from a language perspective then I agree with you totally. However, if I'm running on a 64 CPU machine with a large J2EE application I do need to design differently than if my target is a Windoze box doing animations. The difference in our opinion is in the tuning. I'm confident that if you go to a customer who just spent several million dollars on your app server and tell them that, well, we didn't program thinking about the differences in the threading models between a single CPU Windows box and a 32 processor clustered Sun system you will be thrown out very quickly.

The threading models do matter. For example, what is the major problem with the Linux threading model? Will the Solaris model in Solaris 8+ have the same issues? What were the changes in the Solaris threading model between Solaris 7 and Solaris 9?

In this case the problem with Linux is that they spawn a new process for each thread and then use IPC between the threads. This doesn't scale very well to even 1000 threads. Solaris is now doing something similar but it isn't process based so they scale fine to 10,000 threads or more. So do your write your program so that it can spawn an unlimited number of threads or do you put a govenor on it? These are the O/S specific things you have to think about.
[ October 29, 2004: Message edited by: Scott Dunbar ]
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Scott Dunbar:


Rigid indeed...

I disagree but it may be because of our perspectives. If you are speaking strictly from a language perspective then I agree with you totally. However, if I'm running on a 64 CPU machine with a large J2EE application I do need to design differently than if my target is a Windoze box doing animations. The difference in our opinion is in the tuning. I'm confident that if you go to a customer who just spent several million dollars on your app server and tell them that, well, we didn't program thinking about the differences in the threading models between a single CPU Windows box and a 32 processor clustered Sun system you will be thrown out very quickly.



There are 2 issues here, and I think we agree.

One. Single CPU vs. 64 CPU machine. This is an issue for mutiprocessing optimization, not platoform dependency.

Two. The issue of a particular OS/hardware setup having special features that make it a faster better multiCPU environment. In this case you want to be sure the JVM you pick takes advantage of the platform's abilities. This has nothing to do with how you write Java code, but everything to do with the JVM you choose to run it in.


The threading models do matter. For example, what is the major problem with the Linux threading model? Will the Solaris model in Solaris 8+ have the same issues? What were the changes in the Solaris threading model between Solaris 7 and Solaris 9?



The OS threading models do not matter, the Java threading model is the only one you are concerned about. If you have to be concerned about the OS threading model, you are not programming for Java. Again however, this may impact your choice of JVM.


In this case the problem with Linux is that they spawn a new process for each thread and then use IPC between the threads. This doesn't scale very well to even 1000 threads. Solaris is now doing something similar but it isn't process based so they scale fine to 10,000 threads or more. So do your write your program so that it can spawn an unlimited number of threads or do you put a govenor on it? These are the O/S specific things you have to think about.

[ October 29, 2004: Message edited by: Scott Dunbar ]



1. if you find differences between one jvm and another that affect the way you should write code, that JVM is violating the spec and should be reported. This is good info to know in a platform dependency discussion.

2. if you have particular harware features you want to be sure are put to good use or issues you want to be sure are avoided, check with the JVM writers since that is where it will be done. Again, discussion of one JVM vs. another is good info to have in a platform dependency discussion.

p.s. Not to be disagreeable but there is no way linux spawns processes instead of threads.
[ November 04, 2004: Message edited by: CL Gilbert ]
reply
    Bookmark Topic Watch Topic
  • New Topic