aspose file tools*
The moose likes Threads and Synchronization and the fly likes To scott and Henry Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "To scott and Henry" Watch "To scott and Henry" New topic
Author

To scott and Henry

Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Hello Scott and Henry,

Welcome to Javaranch!

I have some questions for you.

1. What motivated you to write the book ?
2. Is there something that is missing currently in Java Threads that you would like to be added.
3. Why hasn't Sun removed deprecated methods like stop from the Thread class ? It has been a long time since they were deprecated.

Thanks a lot!


Groovy
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

I would also like to know your opinion about the new concurrent Collection classes.
Thanks.
Nigel Browne
Ranch Hand

Joined: May 15, 2001
Posts: 673
Would you please explain the difference between a thread pool and a thread group.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Originally posted by Nigel Browne:
Would you please explain the difference between a thread pool and a thread group.


Thread pool means a pool of threads. It is better to reuse threads rather than create them again and again. When system starts up it may create a pool of threads.

When an application requires a thread it request from the pool and when it finishes using a thread it returns it to the pool. The thread returned to pool does not die and is kept alive.

I am not sure how this pool is implemented, may be the authors could help us.

A thread group represents a set of threads. It is useful to mange the threads. For e.g you could change the thread priority of all the threads in one shot using setPriority method.

Hope this helps.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

Nigel --

Please start a new thread for new questions. Thanks.


[Jess in Action][AskingGoodQuestions]
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Originally posted by Pradeep Bhat:
When an application requires a thread it request from the pool and when it finishes using a thread it returns it to the pool. The thread returned to pool does not die and is kept alive.


Will it ever be killed? Or is it floating in the pool of Threads till the application terminates? Pradeep, I've known about thread pool, but I've never known about the end of the threads lives... Thanks...


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

Joined: May 04, 2004
Posts: 42
The suspend(), stop() and resume() methods are all deprecated because they have the potential to leave objects in inconsistent states. IMO they should be removed from the Thread class completely.
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Originally posted by Jim Bracks:
The suspend(), stop() and resume() methods are all deprecated because they have the potential to leave objects in inconsistent states. IMO they should be removed from the Thread class completely.


Are there any other deprecated methods that were removed from the later JDK versions? Because as far as I know, deprecated methods are still in the later JDK versions so that the applications that are still using the methods can still be working without the need to change the source codes...

Thanks for sharing your opinions...
Jim Bracks
Ranch Hand

Joined: May 04, 2004
Posts: 42
Java 1.4.0 shipped with 22 deprecated classes, 8 deprecated interfaces, 50 deprecated fields, and over 300 deprecated methods and constructors.


dont know about 1.5.
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Originally posted by Nigel Browne:
Would you please explain the difference between a thread pool and a thread group.


A thread pool is a set of reusable pools. This strategy is used for removing the time needed for creating thread instances.
A thread group is a way to group a set of threads that share the same parent. This way of creating threads impose some restrictions on data access.

./pope


blog - InfoQ.com
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Originally posted by Ko Ko Naing:


Will it ever be killed? Or is it floating in the pool of Threads till the application terminates? Pradeep, I've known about thread pool, but I've never known about the end of the threads lives... Thanks...


No it is not to be killed - otherwise the pool would serve to nothing. Rather it is in a Runnable state - meaning it is eligible to run again.

./pope
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Originally posted by Ko Ko Naing:


Are there any other deprecated methods that were removed from the later JDK versions? Because as far as I know, deprecated methods are still in the later JDK versions so that the applications that are still using the methods can still be working without the need to change the source codes...

Thanks for sharing your opinions...


I don't think this is an important issue. Everytime you write code you just need to check the API in order to use not deprecated methods. That's all.

./pope
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18996
    
  40


1. What motivated you to write the book ?
2. Is there something that is missing currently in Java Threads that you would like to be added.
3. Why hasn't Sun removed deprecated methods like stop from the Thread class ? It has been a long time since they were deprecated.


1. To put it into context. The first edition was released in 1997. Subtract about 18th months, the work for this book started about a year after java was released. Basically, at that time, there were very few good books on threading in general, and little advanced books on java, the conditions were perfect for a java threading book.

But to answer your question, We were asked to write a Java book. The actual details on how it happened and by who, is probably lost to history...

2. When the first edition was released, I wanted to put in a chapter on debugging, but it didn't make the cut. (All that got in was a broken appendix about JDB) With the second edition, it didn't make the cut either. In fact, the appendix got removed. And finally, with Java Threads, 3rd edition, the chapter didn't make the cut again...

Thread debugging is seriously becoming an issue with me...

3. Don't know the answer to this one... except maybe they don't want to break older applications?

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18996
    
  40

Originally posted by Pradeep Bhat:
I would also like to know your opinion about the new concurrent Collection classes.
Thanks.


There are two parts to this question... using threads to implement the collection, and using collections for threads.

First, many of the new collection classes are incredibly optimized. Many are implemented optimistically and segmented -- allowing parallel reads and in many cases writes. Many include enhancements for iterators, etc... If you used collections in your applications, you can probably replace the set, hashmap, and list collections and may see improvement... but... be warned, due to complexity, some cases may be slower too.

Second, a new collection type (the queue) was added to support thread programming. Basically, there are a few concurrent patterns that have been developed over the years, and the queue is perfect for these patterns. In fact, there are versions that are actually thread aware, allowing the programming control whether the operation should block or not.

We actually devote a whole chapter to the threading issues of collections in the book.

Henry
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18996
    
  40


Thread pool means a pool of threads. It is better to reuse threads rather than create them again and again. When system starts up it may create a pool of threads.

When an application requires a thread it request from the pool and when it finishes using a thread it returns it to the pool. The thread returned to pool does not die and is kept alive.

I am not sure how this pool is implemented, may be the authors could help us.


JDK 1.5 added a thread pool... And for those with previous versions of Java, or want to know how to implement one, we actually implemented a thread pool in the book. Unfortunately, with the third edition, we had to cut many of the implementation discussions that was in the second edition.

There are actually issues and conditions on when to use, and not use, a thread pool. It is not just as simple as reusing threads. (which we do discuss)

Henry
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Originally posted by Henry Wong:

There are actually issues and conditions on when to use, and not use, a thread pool.

Henry,
Is it like we can configure whether to use or not use Thread pool? I was always thinking that Thread pool is available to the application since the beginning and we cannot avoid to use it...

Thanks...
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18996
    
  40

Originally posted by Ko Ko Naing:

Is it like we can configure whether to use or not use Thread pool? I was always thinking that Thread pool is available to the application since the beginning and we cannot avoid to use it...

Thanks...


The thread pool executor is a class. You need to instantiate it, and pass tasks for it to execute. You don't actually need to use it. And none of your old programs will automatically use it without code modifications.

Henry
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Originally posted by Ko Ko Naing:

Henry,
Is it like we can configure whether to use or not use Thread pool? I was always thinking that Thread pool is available to the application since the beginning and we cannot avoid to use it...

Thanks...


I cannot imagine a problem where using thread pool and not using it would work as solutions.

./pope
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Thanks Henry.

Does the book talk about how to use threads when there are multiple processors or there is no difference between a single processor multiple processor environments as far Java threads are concerned?
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

JDK 1.5 added a thread pool... And for those with previous versions of Java, or want to know how to implement one, we actually implemented a thread pool in the book. Unfortunately, with the third edition, we had to cut many of the implementation discussions that was in the second edition.


How is the thread pool implemented? :roll:
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

The Thread pool Executor class
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executors.html
Nigel Browne
Ranch Hand

Joined: May 15, 2001
Posts: 673
Originally posted by Henry Wong:



There are actually issues and conditions on when to use, and not use, a thread pool. It is not just as simple as reusing threads. (which we do discuss)

Henry


This is where my confusion lies, are not all thread pools based on the ThreadGroup class ? If this is true why was this particular design chosen to implement thread pools.
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
A thread group is completely another notion :-).

./pope
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Originally posted by Pradeep Bhat:
Thanks Henry.

Does the book talk about how to use threads when there are multiple processors or there is no difference between a single processor multiple processor environments as far Java threads are concerned?


It doesn't matter how many processors are on the JVM on which the machine is running. Probably if you have used correctly the threads will be able to see a performance improvement on a multi-processor machine

./pope
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Originally posted by Ali Pope:
Probably if you have used correctly the threads will be able to see a performance improvement on a multi-processor machine.


You mean some kinda mechanisms like pipelining should be used for performance improvement on a multi-processor machine, where we can fully make use of hardware advantage to fulfil the requirements of a problem...

Just my 2 cents...
Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
Originally posted by Ali Pope:


It doesn't matter how many processors are on the JVM on which the machine is running. Probably if you have used correctly the threads will be able to see a performance improvement on a multi-processor machine

./pope


Say I have a standard j2ee application where we dont create threads in the code,

and I have a machine

Machine1: 1800 MHZ Single CPU
Machine2: 450MHZ X 4 CPUs

Machine2 can probably handle more concurrent users but for a single user, wouldnt Machine1 outperform Machine2?
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Originally posted by karthik Guru:


Machine1: 1800 MHZ Single CPU
Machine2: 450MHZ X 4 CPUs


What does it mean a J2EE application for a single use?
The calculus for the above cannot be done without testing/monitoring. I have said "probably" :-).

./pope
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Originally posted by Ko Ko Naing:


You mean some kinda mechanisms like pipelining should be used for performance improvement on a multi-processor machine, where we can fully make use of hardware advantage to fulfil the requirements of a problem...

Just my 2 cents...


In fact nope. Thread management from the point of view of developer is the same in Java (even if you develop a solution that will work on a 2-CPU or 8-CPU machine).

./pope
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18996
    
  40

Originally posted by Pradeep Bhat:
Thanks Henry.

Does the book talk about how to use threads when there are multiple processors or there is no difference between a single processor multiple processor environments as far Java threads are concerned?


Okay, there are two ways to answer this:

Ideally, it should not matter how many processors your computer has. As long as you use threads efficiently, the JVM should schedule different processors per thread -- meaning there should be no difference between using single versus a multiprocessor environments.

However, Java Threads actually spends a whole chapter on multiprocessor environnments -- and a big chapter at that. The issue is what happens if you have one big calculation that is not threaded. You can have a 12 way machine and only 1 processor will be busy, with another getting some time to redraw your GUI.

Chapter 15 is a chapter devoted to refactoring of large loops into multithreaded small ones. It is actually a pretty detailed chapter, and we were very proud of it when we added it to the second edition. Unfortunately, unlike the other chapters, we got zero feedback on this chapter. We don't know if it is because it is not important, or the readers got really burned out by the time we got to it...

For the third edition, it got moved to the very last chapter. In terms of the book, this chapter got the least changes... but it is still an important chapter. This time, hopefully, we'll get some feedback.

Henry
[ October 20, 2004: Message edited by: Henry Wong ]
Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
Originally posted by Ali Pope:


What does it mean a J2EE application for a single use?
The calculus for the above cannot be done without testing/monitoring. I have said "probably" :-).

./pope


I mean single user response time. If there are no threads within out code (as discouraged by j2ee), then can the code take advantage of the fact that there are 4 CPUs?.
So the response times on a single CPU but 1800 MHZ has to be better than that on a 4 CPU box 450 MHZ?
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Karthik:
1.
If there are no threads within out code (as discouraged by j2ee), then can the code take advantage of the fact that there are 4 CPUs?.


I guess this is very much dependent on how the JVM is implemented. As long as JVM can parallize execution yes a single threaded application could in a way take advantage of multi-processors. But as I already said, from the point of view of the developer this is not important.

2.

So the response times on a single CPU but 1800 MHZ has to be better than that on a 4 CPU box 450 MHZ?


This question may be answered only if you deploy the application in both environments and test and monitor it.
As long as a machine is more powerfull than the other (and this computed from the point of view of the target application) it is quite normal to obtain better results on the more powerfull machine ;-).

3.
I mean single user response time.


Indeed a response time is one of the most important metrics for a distributed application (j2ee) and its called throughput. But the throughput is always measured under the condition of the application load (this means: what is the throughput when the application must take care of 100 concurrent requests; or 1000 concurrent requests). This kind of metrics will determine also the scalability of the application.

./pope
[ October 20, 2004: Message edited by: Ali Pope ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: To scott and Henry