Threads
As far as I know there are two ways for creating threads, (1) extendingThread (2) implementingRunnable and encapsulating inThread.
In the project I'm working on I can't extendThread since I'm extending another class already, so I have to go with the second option. This however causes a problem: since I need to maintain aVector object containing all the objects that are going to be acting as threads, I can't access their functionality anymore because they are encapsulated in theThread object.
My question is how to maintain aVector object containing threads while being able to access the functionality of the class encapsulated by theThread class ?
Thanks in advance.
[765 byte] By [
vahidga] at [2007-10-2 8:43:11]
> In the project I'm working on I can't extend
> Thread since I'm extending another class
> already, so I have to go with the second option.
That's a "Good Thing"?
Prefer implementing Runnable to extending Thread. Think of Threads as the workers and Runnables as the job itself. You implement Runnable because your "unit of work" or whatever you want to call it IS-A Runnable -- that is, something that will do its job start-to-finish when you call run. You would only extend Thread if your class IS-A Thread -- that is, it has a reason to do everything Thread does, and you need to slightly add to or modify Thread's behavior.
> This however causes a problem: since I need to maintain a
> Vector object containing all the objects that
> are going to be acting as threads, I can't access
> their functionality anymore because they are
> encapsulated in the Thread object.
That doesn't make sense to me. There's no reason why a Vector of Runnable objects can't have their "functionality accessed".
Please be a little more explicit about what you're doing, what you expect to happen, and what you actually observe.
Please post a [url=http://www.physci.org/codes/sscce.jsp]short, concise, executable example[/url] of what you're trying to do. This does not have to be the actual code you are using. Write a small example that demonstrates your intent, and only that. Wrap the code in a class and give it a main method that runs it - if we can just copy and paste the code into a text file, compile it and run it without any changes, then we can be sure that we haven't made incorrect assumptions about how you are using it.
Post your code between [code] and [/code] tags. Cut and paste the code, rather than re-typing it (re-typing often introduces subtle errors that make your problem difficult to troubleshoot). Please preview your post when posting code.
> My question is how to maintain a Vector object
> containing threads while being able to access the
> functionality of the class encapsulated by the
> Thread class ?
On a side note, prefer ArrayList to Vector. Both offer the same interface (i.e., List), but Vector is an outdated class that was shoehorned into the Collection API. If you absolutely need to have your List synchronized, use Collections.synchronizedList().
Simply maintain a List of the Runnable objects you wish to use. Nothing will be "encapsulated by the Thread class" (except, of course, behavior/state pertinent to the Thread object).
Hi yawmark,
I need all the objects in the Vector to be running, so I have to encapsulate them into Thread objects in order to be able to start them. For example if I have a Vector containing Thread objects that are holding Node objects implementing Runnable (have to have the Node objects in the Thread objects in order to be able to start them):
// Node class - this is suppose to be running in a thread
class Node extends java.rmi.server.UnicastRemoteObject implements Runnable {
int id ;
public Node(int id) throws java.rmi.RemoteException{
this.id = id ;
}
public int getID(){
return id;
}
public void run(){
// do nothing
}
}
// Main method class
public class Main{
public static void main(String[] args){
java.util.List nodes = new java.util.Vector() ;
for(int i = 0 ; i < 10 ; i++){
Thread thread = new Thread(new Node(i));
thread.start();
nodes.add(thread);
}
// nodes.elementAt(2).getID() is not possible now because it is a Thread instance
}
}
In the example above, I can't call methods specific to Node after retrieving objects from the vector since I am actually holding a list of Thread objects. This is just a simple example to make my question clearer, in the application I am working on I have to keep on to a list of nodes that need to be running as threads but these nodes need to interact with eachother by calling Node specific methods.
Hope this has helped and thanks for your time.
So why not just store Nodes rather than Threads in the List?
jverda at 2007-7-16 22:45:23 >
Jeff,Because I can't run Node objects. I need to have a list of Node objects that are running (as threads).
> Jeff,
>
> Because I can't run Node objects. I need to have a
> list of Node objects that are running (as threads).
That answer doesn't make any sense.
After you've put them in the List, when you get them out again, do you do Thread things to them? From the code you've shown here, you definitely can use a List of Nodes rather than of Threads.
It's clear that you need a list of Nodes. You might also need a list of Threads. If you do (which I haven't seen evidence of so far), then I see two main possibilities. I don't know which is more appropriate for your situation:
* Two separate lists.
* A new class that encapsulates a Thread and a Node.
jverda at 2007-7-16 22:45:23 >
> Because I can't run Node objects. I need to have a
> list of Node objects that are running (as threads).
This still doesn't make sense. If you're just starting each job in turn, a List of Node objects will work just fine.
for (Node n : nodes) {
new Thread(n).start();
}
// do operations on nodes...
If you need a list of Thread objects, it'd probably be best to maintain that separately.
Thanks guys for your replies.
I do need the thread objects later on (I am trying to write an application that simulates a peer2peer algorithm). So I'm going to think about whether to maintain another list or making a class that holds both.
Thanks again for your help and a happy new year,
Vahid
I agree with yawmark that it's probably best to maintain two separate list, but it's up to you.
jverda at 2007-7-16 22:45:24 >
