-1

what is the difference between thread and process, i know you think this is duplicate , but seriously no where and nobody given one exact and to the point answer . I am really tired when somebody says thread are light weight process , even books does not clearly mention it why ? So I gone through different stackoverflow answer and made a final answer. I feel it is incomplete. Please contribute to this answer ,as it will really help thousand of people who still struggling to understand this puzzle.

My research reached till here so far ....

Linux calls clone API for creation of thread and creation of process , only difference is there are 28 flags which are configured differently for thread and process. https://stackoverflow.com/a/64942352

enter image description here

Learner09
  • 9
  • 1
  • 5
  • Are you more interested in knowing from the point of view of an application programmer? or are you more interested in the point of view of a kernel developer? The answer from the app developer's perspective it pretty simple, but from the kernel developer's,... not so much. The _implementation_ of threads in Linux has evolved from processes over a number of years, and so, if you look at books or blog posts or anything written, the answer will vary according to the year in which it was written. – Solomon Slow Nov 12 '22 at 20:25
  • @SolomonSlow firsly , I/WE need to know as point of view of application developer . – Learner09 Nov 12 '22 at 20:29
  • Each process has it's own address space. If you create new process (e.g. with `fork()` and modify memory in child process, parent process will NOT see modifications as child got COPY of original address space and has it's own. Theads, in contrast, share the same address space of thread which created them, so modifications by one thread is visible to others. Each process consist of at least one, 'main' thread. This is not the only difference but most significant, i think. – dimich Nov 12 '22 at 20:41
  • @dimich thanks , i have added one row stating that process required IPC whereas thread can communication as they share same address space – Learner09 Nov 12 '22 at 20:53
  • @Learner09 Wording of your question is quite confusing. You are trying to compare processes and threads like equal interchangable entities but they aren't. A process consists of threads (at least one), and each thread always belongs to certain process. *Process takes more time to terminate* comparing to thread termination because kernel have to terminate at least one main thread, and all other resources in addition. If you terminate single main thread in process, e.g. with `pthread_exit()` it takes the same time as process termination, because it IS process termination. – dimich Nov 13 '22 at 00:49
  • If you want an answer in the form of improved table "difference between ...", you should make that an actual table, not an _image_. – Employed Russian Nov 13 '22 at 19:25

1 Answers1

2

I'm not qualified to speak about the implementation of Linux threads. (I've heard that it has been evolving over the past decade or so.) But, the purpose of threads and processes has remained pretty stable:

A thread is an execution path through your program's code. That's pretty much all there is to say about that.

A process is a container for all of the resources needed by an instance of your program; The process has a virtual address space, it has open file handles, it may have sockets, it may have memory mappings, it may own IPC objects, I'm not sure what all else. And, a process has some number of threads. (Always at least one thread, sometimes more.)

The threads in your program do all the work. The process is the place in which they do the work.

Solomon Slow
  • 25,130
  • 5
  • 37
  • 57
  • "A thread is an execution path ..." is _wrong_ -- it's not a (single) execution path. If you delete that statement, your answer will become correct. – Employed Russian Nov 13 '22 at 19:35
  • @EmployedRussian, I think there's two ways of looking at it. There's an in-the-moment way, and there's a big-picture way. The in-the-moment way is to think of a thread as an _agent_ who carries out your instructions—executes your code. The big-picture way, which is also more of a computer-science-y way, is to talk about what the thread _does_ —the "path of execution." The big-picture way also has a closer connection to [why we call them "threads"](https://softwareengineering.stackexchange.com/q/225371/200736), and why we talk about threads "joining" each other. – Solomon Slow Nov 13 '22 at 20:29