LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices

Reply
 
Search this Thread
Old 07-30-2009, 10:20 PM   #1
whho
Member
 
Registered: Feb 2009
Posts: 38

Rep: Reputation: 16
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

Last edited by whho; 07-30-2009 at 10:25 PM.
 
Old 07-31-2009, 12:15 AM   #2
neonsignal
Senior Member
 
Registered: Jan 2005
Location: Melbourne, Australia
Distribution: Debian Wheezy (Fluxbox WM)
Posts: 1,363
Blog Entries: 52

Rep: Reputation: 353Reputation: 353Reputation: 353Reputation: 353
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.

Last edited by neonsignal; 07-31-2009 at 12:17 AM.
 
Old 07-31-2009, 12:22 AM   #3
whho
Member
 
Registered: Feb 2009
Posts: 38

Original Poster
Rep: Reputation: 16
Quote:
Originally Posted by neonsignal View Post
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
 
Old 07-31-2009, 12:38 AM   #4
chrism01
Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.5, Centos 5.10
Posts: 16,261

Rep: Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028
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
 
Old 07-31-2009, 04:36 AM   #5
whho
Member
 
Registered: Feb 2009
Posts: 38

Original Poster
Rep: Reputation: 16
If threads are not processes, why are they assigned a process id? (or is it really a process id?)
 
Old 07-31-2009, 05:29 AM   #6
neonsignal
Senior Member
 
Registered: Jan 2005
Location: Melbourne, Australia
Distribution: Debian Wheezy (Fluxbox WM)
Posts: 1,363
Blog Entries: 52

Rep: Reputation: 353Reputation: 353Reputation: 353Reputation: 353
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).
 
Old 08-01-2009, 09:49 AM   #7
whho
Member
 
Registered: Feb 2009
Posts: 38

Original Poster
Rep: Reputation: 16
Quote:
Originally Posted by neonsignal View Post
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
 
Old 08-01-2009, 10:13 AM   #8
neonsignal
Senior Member
 
Registered: Jan 2005
Location: Melbourne, Australia
Distribution: Debian Wheezy (Fluxbox WM)
Posts: 1,363
Blog Entries: 52

Rep: Reputation: 353Reputation: 353Reputation: 353Reputation: 353
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'.
 
Old 08-02-2009, 11:52 AM   #9
whho
Member
 
Registered: Feb 2009
Posts: 38

Original Poster
Rep: Reputation: 16
Quote:
Originally Posted by neonsignal View Post
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!
 
Old 08-02-2009, 07:12 PM   #10
chrism01
Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.5, Centos 5.10
Posts: 16,261

Rep: Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028
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
 
Old 08-02-2009, 07:24 PM   #11
Ruler2112
Member
 
Registered: Oct 2004
Location: Michigan, US
Distribution: Redhat 7.3, 9.0; Slackware 10, 10.1, 10.2, 11; FreeBSD 7.0; KnoppMyth 5.5
Posts: 125

Rep: Reputation: 16
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to kill a Child and all its subsequent child process in C shayer009 Programming 3 12-04-2007 12:40 AM
Alternative to child in C...thread maybe? zaichik Programming 1 09-09-2005 08:34 PM
Killing a child process from another child marri Programming 6 10-01-2004 07:08 PM
Main thread sending notification to child thread rajesh_b Programming 1 09-22-2004 09:15 AM
Bash Scripting - child process affecting parent process mthaddon Linux - General 1 05-02-2004 01:19 PM


All times are GMT -5. The time now is 02:47 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration