Tilted Forum Project Discussion Community - View Single Post - [Java] Thread class

kel · 11-05-2004, 10:34 AM

Bandarflek, If you inherit from the class you can override the method if you choose. Defining the function in the base class does not remove flexibility from inherited classes, it just provides more functionality by default. All classes inherited from Thread are still Threads (with possibly more added functionality) and the idea of comparison is very likely still valid.

A-J, Custom scheduling is frequently needed in real-time applications. Why assume that the scheduling model java uses is ideal for all applications.

Manalone, I have to disagree with you. It is obvious. How else would you compare them? Lexicographically by thread name? Is it better to not make them comparable at all and lose all potential convenience?

The fact that Thread doesn't implement the comparable interface makes it impossible to put Threads in a sorted data structure without a wrapper class.

No one has presented a reason why NOT to implement the comparable interface. It can only help and not hurt. It has a real application when you want to find a thread of a specific priority in a structure with thousands of threads with thousands of priorities. Without implementing some form of the comparable interface it would be necessary to use a linear search if one wanted to stick with java's built in data structures. It is useful when your scheduling model takes into account the state of hundreds of threads at once when deciding on which priority to run next. For instance if I ask the question how many threads are there of a certain priority, it helps to have them presorted.

What if I asked a more complicated question such as "How many threads are there in a range of priorities that is not necessarily continous?"

A similar attitude was applied to the development of the Object class where default implementations of equals() and hashCode() are given even though they may not always be meaningful in the intended way. One might even want to say (although I am actually not advocating this, I think it's wrong) that the default implementation of Thread should also override the hashCode() function so that it hashes the string instead of the whole object. It would be nice to be able to reference threads by their name in a hashtable.

As a last example so someone can see why this is relevant, let's say we have a real-time system with a producer and a consumer, the consumer has thousands of threads processing something for the consumer of varying priorities. Our custom thread scheduler wants to know if it's being overload by high priority tasks that aren't going to be serviced fast enough. That would be asking the question "How many threads are there of a priority > n." If the thread scheduler sees there are a large number of these threads it could queue a notice to the producer and increase the priority of the communication or networking thread so that the message get's out sooner and the producer is notified that he needs to scale back and offload to another consumer. This system could be a distributed realtime 3d ray tracer. It could also be a robotic arm in a factory.

11-05-2004, 10:34 AM	#5 (permalink)
kel WARNING: FLAMMABLE Location: Ask Acetylene	But... Bandarflek, If you inherit from the class you can override the method if you choose. Defining the function in the base class does not remove flexibility from inherited classes, it just provides more functionality by default. All classes inherited from Thread are still Threads (with possibly more added functionality) and the idea of comparison is very likely still valid. A-J, Custom scheduling is frequently needed in real-time applications. Why assume that the scheduling model java uses is ideal for all applications. Manalone, I have to disagree with you. It is obvious. How else would you compare them? Lexicographically by thread name? Is it better to not make them comparable at all and lose all potential convenience? The fact that Thread doesn't implement the comparable interface makes it impossible to put Threads in a sorted data structure without a wrapper class. No one has presented a reason why NOT to implement the comparable interface. It can only help and not hurt. It has a real application when you want to find a thread of a specific priority in a structure with thousands of threads with thousands of priorities. Without implementing some form of the comparable interface it would be necessary to use a linear search if one wanted to stick with java's built in data structures. It is useful when your scheduling model takes into account the state of hundreds of threads at once when deciding on which priority to run next. For instance if I ask the question how many threads are there of a certain priority, it helps to have them presorted. What if I asked a more complicated question such as "How many threads are there in a range of priorities that is not necessarily continous?" A similar attitude was applied to the development of the Object class where default implementations of equals() and hashCode() are given even though they may not always be meaningful in the intended way. One might even want to say (although I am actually not advocating this, I think it's wrong) that the default implementation of Thread should also override the hashCode() function so that it hashes the string instead of the whole object. It would be nice to be able to reference threads by their name in a hashtable. As a last example so someone can see why this is relevant, let's say we have a real-time system with a producer and a consumer, the consumer has thousands of threads processing something for the consumer of varying priorities. Our custom thread scheduler wants to know if it's being overload by high priority tasks that aren't going to be serviced fast enough. That would be asking the question "How many threads are there of a priority > n." If the thread scheduler sees there are a large number of these threads it could queue a notice to the producer and increase the priority of the communication or networking thread so that the message get's out sooner and the producer is notified that he needs to scale back and offload to another consumer. This system could be a distributed realtime 3d ray tracer. It could also be a robotic arm in a factory. __________________ "It better be funny" Last edited by kel; 11-05-2004 at 10:38 AM..