Subj : Re: Threads and processes on Linux
To   : comp.programming.threads,comp.os.linux.misc,comp.sources.d
From : loic-dev
Date : Thu Mar 31 2005 04:56 am

Hello Gus,

> I have often heard that in a Linux environment there is no difference
> between threads and processes.  I want to know if that is merely
> "rhetoric" or if that is really so.

It is more than "rhetoric". From a scheduler perspective, threads and
processes are the same entity.

Actually, Linux views a thread as a process with some special
properties: it shares with its 'parent task' (the spawning thread) the
things that are needed to make it to *behave like* a thread. Namely,

(o) memory descriptors and all Page tables. This means that the child
task runs in the same memory space as the parent task. All memory
mappings or write operations are visible in both entities.

(o) file system information (root directory, current directory and
umask).

(o) open files

(o) signal handlers.

The fact that threads were modelled as processes is visible when using
LinuxThreads and/or older 2.4.x kernel. For instance, each spawned
thread has a different pid, and are children of the so-called manager
thread.

With the advent of NPTL and 2.6.x kernel, a process *appears* as a
collection of thread, where threads are peers. But it is an
_abstraction_ provided by NPTL: for instance, a sibling relationship
between threads still exists, but is now hidden to you. Inside the
kernel, threads and processes are similar entities (the scheduler won't
even bother to make any distinction).


> For example, I have seen that getpid() in all threads returns the
same value
> (as I think it should).

Only with NPTL.


> This means from the perspective of operations associated with
processes
> (ps, signal etc.), all the threads are viewed as a single entity.

Yes, because NPTL provides an abstraction that let you think it is so.
But, in reality, the threads of a process are different entities.


> Also, if the spawning thread terminates (e.g. it does not do a join
on
> the spawned thread), the spwaned thread also seems to terminate.  In
> other words, the lifetime of a spawned thread does not seem to exceed
> the lifetime of the spawning thread.

Generally speaking, this is not correct. You can perfectly create a
thread that lasts more than the spawner thread. Consider for instance
the following simple program:

#include <stdio.h>
#include <pthread.h>
#include <unistd.h>

void*
my_thread(void* ignore)
{
  int i;

  for (i=5; i>=1; i--) {
    printf ("%d...", i); fflush(stdout);
    sleep(1);
  }
  printf ("0\nCiao!\n");
  return NULL;
}

int
main()
{
  pthread_t tid;

  pthread_create (&tid, NULL, my_thread, NULL);
  printf ("Main terminate\n");
  pthread_exit (NULL);
  printf ("Never reached!\n");
  return 0;
}

If you comment the pthread_exit(NULL) out in the main(), then you get
the behavior that you have described. However, it is not a general
rule, but a particular behavior of the main() thread: when main()
returns, all threads in the process go away.  That's because of how the
C language defines main(), more than anything else.  It's simplest to
imagine that the environment calls main like this:

    exit(main(argc, argv, envp));

So that when main() returns, that return value is passed to exit(),
which tears down the process, and all threads therein.


> So what exactly are we saying when we state that "there is no
> difference between threads and processes on Linux"?

I Hope, things got clearer now. 


Cheers, 
Loic.

.