[prev in list] [next in list] [prev in thread] [next in thread] 

List:       hpux-cxx-dev
Subject:    Re: CXX-DEV: ksleep(RELATIVE_TIMEOUT_VALUE|PTH_SPINLOCK_OBJECT
From:       Rick Jones <rick.jones2 () hp ! com>
Date:       2006-04-28 18:37:47
Message-ID: 445260FB.8000406 () hp ! com
[Download RAW message or body]

Johan Piculell (KA/EAB) wrote:
> Hi.
> We have a customer system where one of our processes sometimes goes wild
> and consumes 300-400% system CPU time. The server is a PA-RISC based
> 16CPU server running 11.23.

Any particular patches installed?  Either in the form of bundles, or 
point patches - especially pthreads ones?

> If I compare a tusc from normal execution with this "hanging" situation
> the most eye catching thing is these lines that can be seen repetedly:
> 
> ksleep(RELATIVE_TIMEOUT_VALUE|PTH_SPINLOCK_OBJECT, 0x24e9454, NULL,
> 0x77ec0900) = -ETIMEDOUT
> sched_yield()
> ................................................................ = 0
> sched_yield()
> ................................................................ = 0
> sched_yield()
> ................................................................ = 0
> ksleep(RELATIVE_TIMEOUT_VALUE|PTH_SPINLOCK_OBJECT, 0x24e9454, NULL,
> 0x77ec0900) = -ETIMEDOUT
> sched_yield()
> ................................................................ = 0
> sched_yield()
> ................................................................ = 0
> sched_yield()
> ................................................................ = 0
> 
> I'm suspecting a condition wait to be the cause of this call but I am
> not sure. We have several threads doing waits and the call chain is
> something like this:

Well, if the ksleep() were for the condition variable itself, the 
parameter would be PTHREAD_CONDVAR_OBJECT (IIRC) not 
PTH_SPINLOCK_OBJECT.  When it is for a mutex, the parameter is 
PTHREAD_MUTEX_OBJECT. (I may have the specific spelling wrong but 
hopefully that conveys the gist of it)

I am _far_ from a threads expert, only someone occasionally encountering 
applications with threads issues, but my understanding is that the 
PTH_SPINLOCK_OBJECT may be an "internal" lock.

> 
> #0  0xc0212f10 in __ksleep+0x10 () from /lib/libc.2
> #1  0xc007a4ec in __mxn_sleep+0xc78 () from /lib/libpthread.1
> #2  0xc004f1e0 in <unknown_procedure> + 0x188 () from /lib/libpthread.1
> #3  0xc004efe0 in pthread_cond_timedwait+0xa4 () from /lib/libpthread.1
> 
> Can anyone make something out of this? We have tried to make a
> testprogram to bail out and produce these ksleep lines but all we get is
> something like this:
> ksleep(PTH_CONDVAR_OBJECT, 0x1364884, 0x19f18054, 0x77ec0308) ... =
> -ETIMEDOUT

Ah, I did get the spelling slightly wrong. Sigh...

> 
> What could possibly make a pthread_cond_timewait call to produce a
> ksleep call with the options
> "RELATIVE_TIMEOUT_VALUE|PTH_SPINLOCK_OBJECT"?
> Is this something that is normal? We have tried to call
> pthread_cond_timewait with unintialized mutex, 0 as time, unlocked
> mutex, but never reproduced any problems.

One guess would be that if there are lots of threads trying to 
manipulate the condvar object you might be able to induce spinning on 
the internal lock.

rick jones

> Thanks and regards
> /Johan
>  _________________________________________________________________
>  To leave this mailing list, send mail to majordomo@cxx.cup.hp.com
>     with the message UNSUBSCRIBE cxx-dev
>  _________________________________________________________________
 _________________________________________________________________
 To leave this mailing list, send mail to majordomo@cxx.cup.hp.com
    with the message UNSUBSCRIBE cxx-dev
 _________________________________________________________________
[prev in list] [next in list] [prev in thread] [next in thread]