Context switching in java concrete case

Question

I came to you with a question regarding threads, processes and context-switching that occurs in java. I have already read other questions pertaining this knowledge, yet I want someone to clarify certain aspects regarding some things I have not quite understood. I have made an example for this aspect.

Suppose we have a class with takes a command and then runs ( in a new Thread) the given command, and creates 3 additional threads that takes each of it's streams (input,error,output) and then prints (for the first two) what it gets.

public class ThreadA extends Thread {

    String command;
    private Frame container;
    public ThreadA(String command,Frame container) {
        this.command = command;
        this.container = container;
    }

    @Override
    public void run() {
        Process p = null;
        try {
            p = Runtime.getRuntime().exec(command);
            new ErrorReadThread(p,container).start();
            new InputReadThread(p,container).start();
            new OutputReadThread(p).start();
            int exitValue = p.waitFor();
            System.out.println("Exit value is : " + exitValue);
        } catch (IOException ex) {
            Logger.getLogger(ThreadA.class.getName()).log(Level.SEVERE, null, ex);
        } catch (InterruptedException ex) {
            Logger.getLogger(ThreadA.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
}

The other 3 types of threads just take as an argument the Process object so they get the correct streams for them and in their run method they print out what they read from the streams(for input/error, obviously not for output).

In the main class we have the following:

public static void main(String[] args) {
    String[] listOfCommands = null;
    MainFrame frame = new MainFrame();
    SwingUtilities.invokeLater(()->{
    frame.setVisible(true); 
    });

    //suppose we initialize list with many different command
    for (String string : listOfCommands) {
        new ThreadA(string,frame).start();
    }
}

Now, suppose that on a certain line read on the errorstream thread, I want it to trigger an update(Graphics g), or a repaint() method on the Frame container which is passed to it. I want the same kind of logic on the inputstream thread also. There are several questions which I have regarding this particular example ( please note that there may be issues regarding the code part, I am more interested in the logic that's behind it and what actually happens):

1. Does each process created in each of the new Threads has it's own virtual space address?

2. Which threads are contained within the process? Since it's known that each process has it's own threads, in the case above, which threads are contained within the processes?

3. Due to how the code is made, when does context-switch happen? Inside the stream threads, where it will call some method in the frame container?

4. Does each process represent a child-process of the application? In this case, does it mean each process is created as a child of the java process?

5. If each process is indeed a child-process, does it mean that context-switch is limited to thread-context and all those threads in each different process actually perform only thread-context-switching ?

If my questions already have answers, please do link me to them. I already read the questions and answers related to this, yet nowehere did I find an explanation on what happens when you run multiple processes on new threads.

Answer 1

1) Does each process created in each of the new Threads has it's own virtual space address?

This is OS dependent but usually yes. When you exec a new Process, this runs in a completely new address space. This is true for most ~unix variants (Linux, OSX).

2) Which threads are contained within the process? Since it's known that each process has it's own threads, in the case above, which threads are contained within the processes?

This is a strange question that doesn't quite make sense. The Java process has it's own threads. When your code calls Runtime.getRuntime().exec(command) this starts another process with at least 1 but possibly many threads that are completely separate from the process that started it.

This is somewhat hinted at by the Process javadocs:

There is no requirement that a process represented by a Process object execute asynchronously or concurrently with respect to the Java process that owns the Process object.

Translation: the process runs in the background separately from the java process that started it.

3) Due to how the code is made, when does context-switch happen? Inside the stream threads, where it will call some method in the frame container?

This doesn't really make sense either. If you have enough processors, a context-switch may not actually happen and the new process might just run in another processor from the one that started it.

Maybe the Java process is doing a lot of IO and the other process is CPU intensive so the Java process immediately gets switched out. Maybe the Java process will continue to run and it will be some time before the new process gets a time slice from the OS. What thread to run on what processor and when to switch out the currently running thread is up to the OS and highly dependent on what each process is doing as well as what else is happening on the hardware.

4) Does each process represent a child-process of the application? In this case, does it mean each process is created as a child of the java process?

This depends on the OS as well. In most ~unix variants (Linux, OSX) there is a concept of a parent process. Just like your shell is the parent to a /bin/ls command then yes, the Java process will be the parent of the process that it creates. It is up to the OS about what being a "parent" means.

5) If each process is indeed a child-process, does it mean that context-switch is limited to thread-context and all those threads in each different process actually perform only thread-context-switching ?

This question isn't quite right as well and any answer is highly OS dependent. Typically the child/parent relationship has nothing to do with the context switching. Process priority can affect context-switching but typically the child and parent have the same process priority. This will mean that all of the threads from the Java process will compete in the OS with any process that it creates, and any other processes already running.

I'm not 100% sure about the difference between "thread" and process context switching or if there is any difference at all. Whether or not a thread or entire process gets switched out of a processor depends a lot on the OS internals and the level of contention that is happening on the hardware.