LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   Difference between Child THREAD and Child PROCESS (https://www.linuxquestions.org/questions/linux-newbie-8/difference-between-child-thread-and-child-process-744043/)

whho 07-30-2009 10:20 PM
Difference between Child THREAD and Child PROCESS
 
Hello,

I am troubleshooting something and I got this problem.

If I do "pstree -p"

It shows,

Code:

        ├─soffice.bin(7734)─┬─{soffice.bin}(7735)
        │                  ├─{soffice.bin}(7736)
        │                  ├─{soffice.bin}(7737)
        │                  └─{soffice.bin}(7743)
However, it does NOT show up in "ps -elf"

Code:
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,

Code:
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

neonsignal 07-31-2009 12:15 AM
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.

whho 07-31-2009 12:22 AM
Quote:
Originally Posted by neonsignal (Post 3626232)
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

chrism01 07-31-2009 12:38 AM
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

whho 07-31-2009 04:36 AM
If threads are not processes, why are they assigned a process id? (or is it really a process id?)

neonsignal 07-31-2009 05:29 AM
Quote:
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).

whho 08-01-2009 09:49 AM
Quote:
Originally Posted by neonsignal (Post 3626492)
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

neonsignal 08-01-2009 10:13 AM
Quote:
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'.

whho 08-02-2009 11:52 AM
Quote:
Originally Posted by neonsignal (Post 3627691)
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!

chrism01 08-02-2009 07:12 PM
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

Ruler2112 08-02-2009 07:24 PM
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.

rampatter 02-16-2015 12:13 AM
Thread and process
 
More about....Thead and Process

Rampt.

EDDY1 02-16-2015 12:22 AM
This thread is over 5 yrs. old.


All times are GMT -5. The time now is 02:28 AM.