[uClibc] pthread problem

Chris Gray chris.gray at kiffer.be
Mon Jun 13 22:43:00 UTC 2005

On Monday 13 June 2005 19:34, Syam Krishna Babbellapati wrote:
> Hi All,
>  I am currently facing a problem regarding pthreads while running on
> MIPS 4Kc processor.
> Environment details: uClibc version is 0.9.26, gcc-3.3.4, linux-2.4.20
> kernel, processor :MIPS 4Kc with MMU.
> When I run the code which is attached below, the following sequence of
> operations occur.
> 1. Main forks - creating a child process
> 2. Child process - issues a pthread_create
> After this, I should ideally see parent, child and the new thread
> getting time slices in a round robin fashion.

Yes and no. "Ideally" maybe in the sense of "this is what I wanted to happen", 
but the POSIX threading standard does not require this behaviour. In fact in 
your example it would be perfectly legitimate for one of the the threads to 
completely monopolise the CPU, shutting out both of the others.

I'm not sure what the current status of fork() is in uClib. The semantics are  
not easy to implement on an MMU-less CPU, so until quite recently the call 
was simply not implemented. I guess nowadays it's implemented on top of 

> One other interesting thing is - if we do a static compilation
> (instead of using shared library) with pthread library, then the
> problem disappears.

Who knows? The code is 100% non-deterministic, so anything can happen. :)

> Also, the same code when run with a gcc on the x86 host works just
> fine irrespective of how it is compiled with no such scheduling
> problems.

Also using uClibc, or maybe glibc or something else? (Compilers don't run 
code, crt0 runs code - assisted by a C library, an OS, and a CPU).

Best wishes,


Chris Gray                      /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGi        http://www.kiffer.be/k/
chris.gray at kiffer.be                         +32 3 216 0369

More information about the uClibc mailing list