[Info-vax] HIBertanting DECthreads process accrues CPU time.

[VAXman- at SendSpamHere.ORG]

In article <panf28-di7.ln1 at SendSpamHere.ORG>, Jim Duff <spam.this at 127.0.0.1> writes:
>On 11/02/2011 4:47 AM, VAXman- @SendSpamHere.ORG wrote:
>> In article <00AAAC90.D13DDCBF at SendSpamHere.ORG>, VAXman-  @SendSpamHere.ORG writes:
>> 
>>> I have a process with three threads.  These three threads are created 
>>> and then, sit on $HIBER until awakened when there is work to do.
>>>
>>> Occasionally, I will see this process (when started) accruing CPU time 
>>> when there is nothing in terms of work for it to do.  I've put various 
>>> markers in the code and *these* threads are not active.  I've used SDA 
>>> and I've viewed the TEBs.  Stack highwater is well below each thread's 
>>> stack limit.
>>> ...
>>> Does anybody have a clue as to what DECthreads is doing here?
>>>
>>> I am convinced there something horked in the thread scheduler.  Sadly,
>>> I cannot use pthread_getcputime_np() on the several internal (negative
>>> sequence number threads) which DECthreads has created to see which of
>>> them is actually accruing this time.  I do know that it's not MY three
>>> threads chewing up this time.
>> 
>> Here's some more info from SDA.  Note threads -2 and -4 are "running" 
>> and are clocking up all the CPU time.  No idea why.  All of the other
>> threads (and I took the time to name my threads) are going nothing at
>> all.
>> 
>> 
>> SDA> PTHREAD THREAD -af
>> 
>> [snip]
>
>Cannot reproduce on IA64 8.3-1H1 with this code:
>
>#include <stdio.h>
>#include <stdlib.h>
>#include <ssdef.h>
>#include <stsdef.h>
>#include <pthread.h>
>#include <lib$routines.h>
>#include <starlet.h>
>
>static void *the_thread (void *arg) {
>
>int r0_status;
>pthread_t my_id;
>
>    my_id = pthread_self ();
>
>    r0_status = pthread_detach (my_id);
>    if (r0_status != 0) {
>        printf ("Thread %d can't detach\n", my_id);
>        sys$exit ();
>    }
>
>    r0_status = sys$hiber ();
>    printf ("Thread %d awake\n", my_id);
>
>    pthread_exit ((void *)1);
>    return (void *)1;
>}
>
>
>int main (void) {
>
>int r0_status;
>pthread_t thread_id[3];
>int i;
>
>    for (i = 0; i < 3; i++) {
>        r0_status = pthread_create (&thread_id[i],
>                                    0,
>                                    the_thread,
>                                    NULL);
>        if (r0_status != 0) {
>            printf ("Can't start thread\n");
>            exit (EXIT_FAILURE);
>        }
>    }
>
>    r0_status = sys$hiber();
>}
>
>Compiled with CC/REENT=MULTI
>Linked with LINK/THREAD=(UP,MULTI)
>
>What architecture/VMS version/pthreads version are you running, Brian?

I did fail to post the architecture and VMS version.  This should answer
both: OpenVMS V8.3-1H1.  

The output of the one SDA did show the register stack space which would
have been a giveaway that this was Itanium.



>You say "occasionally".  Does it happen after wakeups?  I'd be tempted
>to swap out $HIBER and $WAKE for pthreads conditions and see if that
>makes it go away.

This happens upon STARTUP... not all the time.  I may have to stop and
start the process several times to get it to begin chewing up this CPU
time.

The three threads haven't don't a thing at startup other than get them-
selves created.  The two thread created by DECthread (VP null threads)
known as -2 and -4 in the SDA> PTHREAD THREAD -af output, are the ones
chewing up the time.  I've been trying to sort this out via the source
listings but that fugly C code gives me headache.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.