Question

I know we can have ‘parents’ and ‘children’ when we are talking about processes. But is it possible to get parent Thread name?

I did my research, but I have found answer only for .Net

---

Edit: I tried setting names:

public class Main {

    public static void main(String[] args) {
        Thread r = new ThreadA();
        r.start();
    }

}



public class ThreadA extends Thread {
    public void run() {
        Thread.currentThread().setName("Thread A");
        System.out.println("Here  " + Thread.currentThread().getName());
        Thread r = new ThreadB();
        r.setName(Thread.currentThread().getName());
        r.start();
    }
}

public class ThreadB extends Thread {
    public void run() {
        Thread.currentThread().setName("Thread B");
        System.out.println("Here " + Thread.currentThread().getName());
        Thread r = new ThreadC();
        r.setName(Thread.currentThread().getName());
        r.start();
    }
}

public class ThreadC extends Thread {
    public void run() {
        Thread.currentThread().setName("Thread C");
        System.out.println("Here " + Thread.currentThread().getName());
    }
}

Answer 1

I know we can have ‘parents’ and ‘children’ when we are talking about processes. But is it possible to get parent Thread name?

A thread does not have a reference to the parent thread so there is no way for you to get the name of the parent from a particular thread. In looking at the code, the parent thread is used to get daemon status, priority, and other information but the name is not stored in the new Thread object.

You mentioned that you need to have the name of the threads so you can group those that “go together in a control flow”. I would look into ThreadGroups. They aren’t used too often but you might want to in this case:

ThreadGroup threadGroup = new ThreadGroup("mythreadgroup");
Thread thread = new Thread(threadGroup, new Runnable() {...});
...
// then you can do such methods as
threadGroup.enumerate(...);

With thread-groups you can tie multiple threads together. You can, of course, do this with a collection as well yourself.

---

Edit:

You mentioned that the real issue is how can you measure the “time spent” in each component of a distributed system – in this case the RMI handlers.

I’m afraid there is no easy answer here. For wall clock, you are going to have to compare the System.currentTimeMillis() at the start of each RMI method call with the time from the end. You can also use the following code to test the CPU time used by the thread.

ThreadInfo threadInfo =
    ManagementFactory.getThreadMXBean().getThreadCpuTime(thread.getId()); 

To get the “user” time you use getThreadUserTime(...). I’m not sure thread-ids are reused so maybe all you need to do is record all of the thread-ids in your RMI calls in a collection and then note their CPU and user times in a monitoring thread.

I suspect the RMI threads have a particular name so your monitoring thread could find the threads in the thread list to do this but you are not going to be able to determine which thread is handling which RMI request.

Lastly, one thing to consider is to take time stamps at a number of points in the process and to pass this long[] around between calls. This would add some small percentage of data overhead but then you would be able to get a good feeling about the performance of the various different parts of your distributed system.