0

Apologized posting the above question here because i read few same kind of thread here but still things is not clear.

As we know that Both processes and threads are independent sequences of execution. The typical difference is that threads (of the same process) run in a shared memory space, while processes run in separate memory spaces. (quoted from this answer)

the above explanation is not enough to visualize the actual things. it will be better if anyone explain what is process with example and how it is different than thread with example.

suppose i start a MS-pain or any accounting program. can we say that accounting program is process ? i guess no. a accounting apps may have multiple process and each process can start multiple thread.

i want to visualize like which area can be called as process when we run any application. so please explain and guide me with example for better visualization and also explain how process and thread is not same. thanks

Community
  • 1
  • 1
Mou
  • 15,673
  • 43
  • 156
  • 275

1 Answers1

0

suppose i start a MS-pain or any accounting program. can we say that accounting program is process ?

Yes. Or rather the current running instance of it is.

i guess no. a accounting apps may have multiple process and each process can start multiple thread.

It is possible for a process to start another process, but relatively usual with windowed software.

The process is a given executable; a windowed application, a console application and a background application would all each involve a running process.

Process refers to the space in which the application runs. With a simple process like NotePad if you open it twice so that you have two NotePad windows open, you have two NotePad processes. (This is also true of more complicated processes, but note that some do their own work to keep things down to one, so e.g. if you have Firefox open and you run Firefox again there will briefly be two Firefox processes but the second one will tell the first to open a new window before exiting and the number of processes returns to one; having a single process makes communication within that application simpler for reasons we'll get to now).

Now each process will have to have at least one thread. This thread contains information about just what it is trying to do (typically in a stack, though that is certainly not the only possible approach). Consider this simple C# program:

static int DoAdd(int a, int b)
{
    return a + b;
}
void Main()
{
    int x = 2;
    int y = 3;
    int z = DoAdd(x, y);
    Console.WriteLine(z);
}

With this simple program first 2 and 3 are stored in places in the stack (corresponding with the labels x and y). Then they are pushed onto the stack again and the thread moves to DoAdd. In DoAdd these are popped and added, and the result pushed to the stack. Then this is stored in the stack (corresponding with the labels z). Then that is pushed again and the thread moves to Console.WriteLine. That does its thing and the thread moves back to Main. Then it leaves and the thread dies. As the only foreground thread running its death leads to the process also ending.

(I'm simplifying here, and I don't think there's a need to nitpick all of those simplifications right now; I'm just presenting a reasonable mental model).

There can be more than one thread. For example:

static int DoAdd(int a, int b)
{
    return a + b;
}
static void PrintTwoMore(object num)
{
    Thread.Sleep(new Random().Next(0, 500));
    Console.WriteLine(DoAdd(2, (int)num));
}
void Main()
{
    for(int i = 0; i != 10; ++i)
        new Thread(PrintTwoMore).Start(i);
}

Here the first thread creates ten more threads. Each of these pause for a different length of time (just to demonstrate that they are independent) and then do a similar task to the first example's only thread.

The first thread dies upon creating the 10th new thread and setting it going. The last of these 10 threads to be running will be the last foreground thread and so when it dies so does the process.

Each of these threads can "see" the same methods and can "see" any data that is stored in the application though there are limits on how likely they are to stamp over each other I won't get into now.

A process can also start a new process, and communicate with it. This is very common in command-line programs, but less so in windowed programs. In the case of Windowed programs its also more common on *nix than on Windows.

One example of this would be when Geany does a find-in-directory operation. Geany doesn't have its own find-in-directory functionality but rather runs the program grep and then interprets the results. So we start with one process (Geany) with its own threads running then one of those threads causes the grep program to run, which means we've also got a grep process running with its threads. Geany's threads and grep's threads cannot communicate to each other as easily as threads in the same process can, but when grep outputs results the thread in Geany can read that output and use that to display those results.

Jon Hanna
  • 110,372
  • 10
  • 146
  • 251
  • thanks for answer. point out the area in program which should be called as process. – Mou May 08 '15 at 12:04
  • u said "That does its thing and the thread moves back to Main. Then it leaves and the thread dies. As the only foreground thread running its death leads to the process also ending." this is not clear to me like what u try to say. which thread will die....main thread ? in ur first example there was no thread except main thread created when program will run. – Mou May 08 '15 at 12:08
  • 1
    The process is the entire running instance of the application. It's not an "area in the program"; if the code of the program is like a theatre script, then the process is like a performance. – Jon Hanna May 08 '15 at 12:10
  • thanks. please see my 2nd comment and please answer. – Mou May 08 '15 at 12:11
  • 1
    Each thread comes to an end when it has nothing else to do. If there are no more threads, then no more process. To add to the theatre analogy, when the last actor leaves the stage for good, the play is over. (Analogies being limited there are exceptions and problems with that, in particular a "background" thread will be killed automatically if there are no more "foreground" threads). – Jon Hanna May 08 '15 at 12:12
  • if possible give me a example to start a sub process from a main process ? – Mou May 08 '15 at 12:12
  • 1
    If I was to add a C# example it would be using `Process.Start`. To actually do something useful with that is more complicated than starting a new thread, which in itself is a reason why multiple threads are easier to work with than multiple processes). – Jon Hanna May 08 '15 at 12:14
  • when we start any console apps or win apps then a main thread start. main thread is always foreground thread or background? – Mou May 08 '15 at 12:15
  • 1
    Always foreground. You always have to have at least one foreground thread. Too continue the theatre analogy you always have to have at least one actor. Background threads are like the poor kid who ended up playing "tree" in a school play; when the last real actor finishes the play is over and we don't care about him! – Jon Hanna May 08 '15 at 12:17
  • beside Process.Start() can't we start other process from main process like starting many thread from main thread....? – Mou May 08 '15 at 12:20
  • I don't get what you mean; beside starting a process can't we start a process? I don't get you. – Jon Hanna May 08 '15 at 12:26
  • i am trying to know when we start our application which is developed by c#. suppose there is a button and i want to start a sub process when user click on that button. is it possible to start a sub process from main process without using Process.Start() ? – Mou May 08 '15 at 12:39
  • No. Well, you could e.g. p/invoke the creation of a new process, but it's the same thing. – Jon Hanna May 08 '15 at 12:47