Prev: A question about stdout and the shell
Next: sending/handling INT signal in child processes in bash
From: saurabh on 6 Jul 2010 01:58
I was going through thread basics in APUE(Richard Stevens).During
explaination of programm 11.2.
here is an almost same programm.

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


pthread_t tid;
void printids(const char* msg)
{
pid_t pid=getpid();
pthread_t tid=pthread_self();
printf("[%s]:->process id:%u threadid:%u\n",msg,pid,tid);

}
void* thread_function(void* arg)
{
printids("new thread");
return (void*)0;
}

int main()
{
printids("main thread");
int err=pthread_create(&tid,NULL,thread_function,NULL);
if(err!=0)
{
printf("Could not create thread");
return 1;
}
sleep(1);
return 0;
}
</code>

Here stevens suggests that Linux uses clone() for pthread
implementation and that is why process ids for both the threads are
different.But i ran the programm and observed that process ids for
both the threads is same.
I was wodering if Linux has changed it's implementation.
I hope I understood it all right.
Need your help on this.

--Saurabh
From: Nicolas George on 6 Jul 2010 03:57
saurabh wrote in message
<e98aa969-206f-4ac3-980f-d9c7a4bbbb91(a)n8g2000prh.googlegroups.com>:
> Here stevens suggests that Linux uses clone() for pthread

Linux even uses clone() for fork(). More precisely, the three system calls
fork, vfork and clone are all trivial wrappers around the same internal
function adding default values for missing parameters. The internal function
itself has almost the same parameters as clone. Any call to fork or vfork
can be written as a call to clone with the correct flags.

(Relatively) recent glibc built for (relatively) recent kernels use the
clone system call for the fork function.

> I was wodering if Linux has changed it's implementation.

The scheduler and process management was completely rewritten during the
development of the 2.6 series to make room for more reliable threads. The
corresponding piece of the glibc was rewritten at the same time, replacing
the old LinuxThreads hack by Xavier Leroy by a complete and reliable
implementation called NPTL.

See <URL: http://en.wikipedia.org/wiki/Linuxthreads > and <URL:
http://en.wikipedia.org/wiki/NPTL > for more details.
From: Mikko Rauhala on 6 Jul 2010 06:40
On 06 Jul 2010 07:57:54 GMT, Nicolas George <nicolas$george(a)salle-s.org> wrote:
> The scheduler and process management was completely rewritten during the
> development of the 2.6 series to make room for more reliable threads. The
> corresponding piece of the glibc was rewritten at the same time, replacing
> the old LinuxThreads hack by Xavier Leroy by a complete and reliable
> implementation called NPTL.

I'll add the further explication that indeed one of the major
differences between those two is that NPTL presents the same
pid to all threads, even though they are clone()d. This was not
the case on LinuxThreads.

(The other major difference is signal handling, LinuxThreads
not being POSIX-compliant wrt. that either.)

--
Mikko Rauhala <mjr(a)iki.fi> - http://www.iki.fi/mjr/blog/
The Finnish Pirate Party - http://piraattipuolue.fi/
World Transhumanist Association - http://transhumanism.org/
Singularity Institute - http://singinst.org/
From: Rainer Weikusat on 6 Jul 2010 09:03
saurabh <saurabhenjoys(a)gmail.com> writes:
> I was going through thread basics in APUE(Richard Stevens).During
> explaination of programm 11.2.

[...]

> Here stevens suggests that Linux uses clone() for pthread
> implementation and that is why process ids for both the threads are
> different.But i ran the programm and observed that process ids for
> both the threads is same. I was wodering if Linux has changed it's
> implementation.

Yes. The implementation of the getpid system call was changed to no
longer return the id of the entity scheduled by the kernel but a
so-called 'thread group id' which was newly invented for this
purpose. The old value, which used to be used as 'process id', is
still available using the (also newly invented) gettid system call.
 | 
Pages: 1
Prev: A question about stdout and the shell
Next: sending/handling INT signal in child processes in bash