aspose file tools*
The moose likes Threads and Synchronization and the fly likes Does Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Does "Java Threads" book discuss OS Platform Dependency issue?" Watch "Does "Java Threads" book discuss OS Platform Dependency issue?" New topic
Author

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

Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
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...


Co-author of SCMAD Exam Guide, Author of JMADPlus
SCJP1.2, CCNA, SCWCD1.4, SCBCD1.3, SCMAD1.0, SCJA1.0, SCJP6.0
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
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


blog - InfoQ.com
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18978
    
  40

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 ]

Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
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
Sheriff

Joined: Sep 28, 2004
Posts: 18978
    
  40

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
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

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
Sheriff

Joined: Sep 28, 2004
Posts: 18978
    
  40

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

Joined: Jun 08, 2002
Posts: 3178
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

Joined: Jul 12, 2004
Posts: 995
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

Joined: Jul 12, 2004
Posts: 995
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
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608

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.


Tony Morris
Java Q&A (FAQ, Trivia)
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18978
    
  40

- 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

Joined: Oct 05, 2001
Posts: 1170

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.
Scott Dunbar
Ranch Hand

Joined: Sep 23, 2004
Posts: 245
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 ]

<a href="http://forums.hotjoe.com/forums/list.page" target="_blank" rel="nofollow">Java forums using Java software</a> - Come and help get them started.
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

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 ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Does "Java Threads" book discuss OS Platform Dependency issue?