Difference between Child THREAD and Child PROCESS

Hello,

I am troubleshooting something and I got this problem.

If I do "pstree -p"

It shows,

        ├─soffice.bin(7734)─┬─{soffice.bin}(7735)
        │                   ├─{soffice.bin}(7736)
        │                   ├─{soffice.bin}(7737)
        │                   └─{soffice.bin}(7743)

However, it does NOT show up in "ps -elf"

ps -elf | grep soffi
0 S whho      7734     1  0  80   0 - 36435 -      11:14 pts/2    00:00:03 /usr/lib/openoffice/program/soffice.bin -splash-pipe=5
0 S whho      7833  7759  0  80   0 -   751 -      11:21 pts/3    00:00:00 grep soffi

I was wondering if 7735, 7736, 7737, 7743 were really processes. Then I checked /proc, I could cd to /proc/7735, /proc/7736, etc, but I could not ls them out.

I looked at the man page of "pstree", it says,

Child threads  of a process are found under the parent process and are shown with the process name in curly braces, e.g.

           icecast2---13*[{icecast2}]

So, what does all this mean? Does it mean that 7735, 7736, 7737, 7743 are just threads but not processes? If so, why could I cd to /proc/<id> but not see them in "ps -elf".

Would somebody please help me?

Thanks!

whho

In a multitasking system, whether running on multiple CPUs/cores or not, the aim is to make it look like you can execute more than one task at the same time.

Both processes and threads refer to a type of multitasking (ie, separate streams of execution). As we currently use the terms, the main distinction is that processes have their own context (usually meaning data space), while threads have a shared context.

Because of this, you end up with a hierarchy, with each process having one or more threads.

Early Unix systems only had 'processes'. The advantage of threads is that the CPU can switch from thread to thread without having to also change all the address context state, which reduces overheads. So they have been implemented as a second layer. Older commands such as ps were originally written when there were no threads.

Originally Posted by neonsignal In a multitasking system, whether running on multiple CPUs/cores or not, the aim is to make it look like you can execute more than one task at the same time. Both processes and threads refer to a type of multitasking (ie, separate streams of execution). As we currently use the terms, the main distinction is that processes have their own context (usually meaning data space), while threads have a shared context. Because of this, you end up with a hierarchy, with each process having one or more threads. Early Unix systems only had 'processes'. The advantage of threads is that the CPU can switch from thread to thread without having to also change all the address context state, which reduces overheads. So they have been implemented as a second layer. Older commands such as ps were originally written when there were no threads.

Thank you for your reply and the explanation!

I am wondering if there is any command to view or manage the threads, like killing them and so on.

I know that fork() can spawn a new process? How can I spawn a new thread?

Thanks again!

whho

Threads in C:
https://computing.llnl.gov/tutorials/pthreads/
http://www.cs.cf.ac.uk/Dave/C/node32.html

Perl:
http://perldoc.perl.org/threads.html

If threads are not processes, why are they assigned a process id? (or is it really a process id?)

If threads are not processes, why are they assigned a process id

Good point. Looks like the old pthreads in Linux didn't comply to the POSIX standard and were a bit of a kludge (implemented by cloning processes).

The current pthread library (NPTL) does not have separate process ids for the threads (support for this library is in the 2.6 kernels).

Originally Posted by neonsignal Good point. Looks like the old pthreads in Linux didn't comply to the POSIX standard and were a bit of a kludge (implemented by cloning processes). The current pthread library (NPTL) does not have separate process ids for the threads (support for this library is in the 2.6 kernels).

Thank you Neon!

Do you mean that programs can choose which thread library to use? If they choose to use an old one, they end up creating threads implemented by process-like clones with different pids, right?

I just felt that it was a bit weird or inconsistent when I could do "ls /proc/7735" but couldn't do "ls /proc/ | grep 7735".

Thanks again!

whho

Do you mean that programs can choose which thread library to use?

Sort of - my understanding is that the LinuxThread library is being phased out (it is not in the glibc anymore), in favor of the NPTL. So it will only be older projects like StarOffice that have what I will call 'pseudo-threads'.

Originally Posted by neonsignal Sort of - my understanding is that the LinuxThread library is being phased out (it is not in the glibc anymore), in favor of the NPTL. So it will only be older projects like StarOffice that have what I will call 'pseudo-threads'.

I see! Thanks again!

When I did threads in Perl (Perl is written in C, like most higher level langs), the kernel version was the determining factor: 2.4.x meant I'd see each thread as a separate process id. 2.6.x meant I'd only see the one pid for the main process.

HTH

Something I'd like to throw in is that in a cluster environment, processes are able to migrate while threads are not. (A cluster is where you have a multitude of computers networked together and they collaborate to accomplish a given task.)

I used OpenMosix for this a while back and was surprised at how efficient things went after modifying my program to be multi-process. Basically, I had a large amount of data to process and then write to a database. I read the file and spawned a separate process for each record, having the results dumped to a file via a network port. Each process received the string, chewed on it as long as it needed to, and wrote out the results. It was very simple to migrate and easy to control with the Parallel::ForkManager perl module. I used an OpenMosix LiveCD on a bunch of workstations after hours and accomplished in one night what would've taken my box over two months to do! Threads were useless for this though; since they share memory with the calling application, they couldn't migrate to another machine.

More about....Thead and Process

Rampt.

This thread is over 5 yrs. old.