Multithreading problems with uClibc 0.9.30.1

[Lennart Sorensen]

On Mon, Jan 11, 2010 at 07:51:12PM +0100, Andrea Tassi wrote:
> Hi,
> 
> I performed some tests with the uClibc 0.9.30.1 about the
> multithreading. I have a problem: when I execute this program,
> 
> #include <pthread.h>
> #include <stdio.h>
> #include <stdlib.h>
> 
> struct thrdata {
>     int thrnum;
>     pthread_t t;
> } th[] = {
>     {0,(pthread_t)0},
>     {0,(pthread_t)0},
>     {0,(pthread_t)0},
>     {0,(pthread_t)0},
>     {0,(pthread_t)0},
>     {0,(pthread_t)0},
>     {0,(pthread_t)0},
>     {0,(pthread_t)0}
> };
> 
> static void *thread_code(void *p);
> 
> main(int argc, char *argv[]) {
>     int i;
>     int nops = sizeof(th)/sizeof(th[0]);
> 
>     for(i=0; i<nops; i++)
>     {
>         th[i].thrnum = i;
>         pthread_create(&th[i].t, NULL, thread_code, (void *)&(th[i]));
>     }
> 
>     for(i=0; i<nops; i++) {
>         pthread_join(th[i].t, NULL);
>     }
> 
>     printf("All threads returned, exiting.\n");
> 
>     exit(0);
> }
> 
> static void *thread_code(void *p) {
>     sleep(10);
> 
>     return(NULL);
> }
> 
> it should create exactly 8 threads but with "ps" I can see that the
> instruction pthread_create(.....) forks: you can see that there are 10
> instances with different PIDs of the sane example program (called
> test):
>  1426 root     16952 S    /tmp/test
>  1427 root     16952 S    /tmp/test
>  1428 root     16952 S    /tmp/test
>  1429 root     16952 S    /tmp/test
>  1430 root     16952 S    /tmp/test
>  1431 root     16952 S    /tmp/test
>  1432 root     16952 S    /tmp/test
>  1433 root     16952 S    /tmp/test
>  1434 root     16952 S    /tmp/test
>  1435 root     16952 S    /tmp/test
> 
> Could you explain me how is this possible? Thank you.

Linux is allowed to represent threads however it wants.  If the threads
were done in user space entirely (including scheduling of threads) then
you should of course have only one pid.  But since the kernel helps out
with scheduling and such, it is perfectly reasonable to treat them as
lightweight processes.  They somewhat are after all.  They have a stack,
an instruction pointer, a cpu state, etc.  They just don't have their
own memory space.

-- 
Len Sorensen