[uClibc] pthread problem
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
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).
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