Conference hydra::axp-developer

3703.0. "BAesema Ltd - Point 29864" by KZIN::ASAP () Wed Jun 04 1997 04:31

    Company Name :  BAesema Ltd - Point 29864
    Contact Name :  Rod Blackwood
    Phone        :  0141 204 2737 extn 2154
    Fax          :  0141 221 6435
    Email        :  [email protected]
    Date/Time in :   4-JUN-1997 08:30:47
    Entered by   :  John Wood
    SPE center   :  REO

    Category     :  vms
    OS Version   :  7.1
    System H/W   :  


    Brief Description of Problem:
    -----------------------------

From:	RDGENG::MRGATE::"RDGMTS::PMDF::mail.dec.com::McGinnity"  3-JUN-1997 16:57:51.77
To:	RDGENG::ASAP
CC:	
Subj:	ESCALATION: POINT  , Company  TO ASAP READING:

From:	NAME: Tanya McGinnity <[email protected]@PMDF@INTERNET>
To:	NAME: 'ASAP REO Escalation' <IMCEAX400-c=US+3Ba=+20+3Bp=DIGITAL+3Bo=SBUEURMFG+3Bdda+3ASMTP=asap+40reo+2Emts+2Edec+2Ecom+3B@mail.dec.com@PMDF@INTERNET>

Hello - 

POINT Log Number	 29864
Company Name 	BAesema Ltd
Engineers name	Rod Blackwood	
Telephone Number 	0141 204 2737 extn 2154	
Fax Number		 0141 221 6435
E-mail Address	[email protected]

Operating System, Version	Open VMS
Platform			

Problem Statement		
I have another problem to do with Posix threads on Alpha OpenVMS 7.1.


Could you please pass this on to an engineer
and see if they can suggest anything ?



I have two threaded applications.
They are written in C++ and are built on a MASCOT kernel
which we have recently ported to Posix threads on Alpha OpenVMS 7.1.
Both are network applications which declare a service and then
accept connections from clients either via TCP/IP or DECnet.

One application has 6 threads and works fine.

The other has over 100 threads and appears to get about
halfway through its initialisation before hanging up

When it hangs up:

 the MONITOR utility showing the CPU modes at
37% interrupt, 49% kernel and 14% user.

 show process/cont shows the process COM all the time

 show process/quotas shows the following:

> CPU limit:                      Infinite  Direct I/O limit:       150
 Buffered I/O byte count quota:     89376  Buffered I/O limit:     150
 Timer queue entry quota:              10  Open file quota:         45
 Paging file quota:                473424  Subprocess quota:        10
 Default page fault cluster:           64  AST quota:              247
 Enqueue quota:                      2000  Shared file limit:        0
 Max detached processes:                0  Max active jobs:          0

 show device/files shows that the program has opened all of its 55 files

 the program's traces show that it has created about 2142 mutexes,
and is trying to create its third or fourth activity (thread)


I am quite prepared to believe we have coding errors,
probably in the pthread MASCOT kernel as it is new.

The code to create a thread is as follows:

	pthread_attr_setstacksize (&thread_attr, get_stack_size());
        struct sched_param schedparam;
        schedparam.sched_priority = get_mapped_priority();
	pthread_attr_setschedparam (&thread_attr, &schedparam);
	pthread_create (&thread, &thread_attr, root, this);

where the following are members of the activity object:

    pthread_attr_t  thread_attr;
    thread_type     thread;
    int get_stack_size();
      // returns the stack allocation for the activity
      // passed as a parameter to the object's constructor

root is the function which runs in the thread and
this is the object passed to the function


I am less suspicious of the rest of the code,
as it runs fine on SunOS, Solaris, HP-UX and Win32,
with different MASCOT kernels.
(only the Win32 MASCOT kernel uses threads).

 
Hovever, as the smaller application works and the larger one doesn't,
and as the application hangup has the CPU using lots of interrupt
and kernel time, I wonder if there may be a resource problem
with Posix Threads.  The activities have a couple of mutexes each,
so could we be running out of mutexes ? 


I would really appreciate any pointers you could give
on any VMS resource issues with Posix Threads
or any patch kits for Posix Threads under Alpha OpenVMS 7.1.


all the best,

Rod.


-- 


Rod Blackwood
Development Manager - LIFESPAN
BAeSEMA
1 Atlantic Quay,
Broomielaw,
Glasgow
G2 8JE



In replying, please use [email protected]

Thanks in advance

Tanya Mc Ginnity


RFC-822-headers:
Received: from reopf1.reo.dec.com by rg71rw.reo.dec.com (PMDF V5.0-7 #15552)
 id <[email protected]> for [email protected]; Tue,
 03 Jun 1997 10:55:20 +0100
Received: by reopf1.reo.dec.com with SMTP
 (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
 id <[email protected]>; Tue, 03 Jun 1997 10:56:53 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63