[ELDK] Problem with pthread_cond_wait on 8xx?

Frank Svendsbøe frank.svendsboe at gmail.com
Wed Sep 23 14:38:50 CEST 2009


On Wed, Sep 23, 2009 at 2:13 PM, Detlev Zundel <dzu at denx.de> wrote:
> Hi Frank,
>
>> I have a problem with high CPU load on 8xx when using pthread_cond_wait.
>> I'm using the glibc v2.6 that came with ELDK 4.2, compiled with NPTL
>> support. The same code compiled for x86 works fine (but then using
>> glibc 2.9). I'm running torvalds mainline kernel v2.6.26-rc2.
>>
>> Can anyone here using ELDK 4.2 on 8xx or another PowerPC target try to
>> compile the program listed below and check the CPU load when running
>> it? Or pinpoint a problem with the code.
>>
>> My current assumption is that the glibc pthread_cond_wait call is
>> implemented using
>> busywaiting/spinlocking on 8xx, or something is wrong in the kernel.
>
> Actually I can reproduce both of your behaviours on my x86 and on a
> PowerPC system ;)
>
> I don't understand why this is the case, but if I compile the program
> without "-lpthread" I have ~100% CPU utilization on both systems.  If I
> do "the right thing" and compile with "-lpthread" everything is fine on
> both systems.
>

Thanks for testing the code ;-)

What PPC target did you test it on, what version of the standard C library
do you use, and what kernel?

If I don't link it against libpthread, I get link errors (unresolved
functions). I assume
you're using the same toolchain (ELDK 4.2), so this is strange. IOW, I have to
link with -lpthread, and you don't. How come?

> Maybe someone here on this list can explain this?
>

Yes I really hope so. The best would be that someone could pinpoint
a problem with the example code, and why the behaviour is different on
different targets. In case I don't find any solution, I will probably need to
upgrade/downgrade the kernel, switch to using uclibc/eglibc, or upgrade
glibc to v2.9. Do you plan to upgrade the ELDK anytime soon (ie. newer
glibc for instance)?

FYI: I've used getconf and verified that I'm using the NPTL enabled pthreads
library on the 8xx.

Best regards,
Frank

> Cheers
>  Detlev
>
> --
> There is no need to be  rigid in carrying out policies about what changes
> to install.  To do a good job of maintaining Emacs doesn't require acting
> like government bureaucrats.
>                -- Richard Stallman <E1MIx3Y-0005iZ-OH at fencepost.gnu.org>
> --
> DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
>


More information about the eldk mailing list