[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference clt::cma

Title:	DECthreads Conference

Moderator:	PTHRED::MARYSTEON

Created:	Mon May 14 1990
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	1553
Total number of notes:	9541

1552.0. "which VMS quota/limit for pthread mutex?" by RDGENG::WOOD_J (John.Wood@reo.dec.com) Wed Jun 04 1997 14:35

A s/w developer has a problem with his C++ application which uses
POSIX threads on OpenVMS Alpha v7.1. It works when he runs the appln
configured for a small number of threads & mutexes, but hangs when
he configures it for a large number of threads (~100) and mutexes
(~2,100).

It would help in troubleshooting this to know what VMS resource
POSIX mutexes are mapped to. E.g. is ENQLM relevent? Or if I do
ANALYSE/SYSTEM then SHOW PROC there is a "Mutex count" field: 
-is this used?

Thanks,
  John Wood

T.R	Title	User	Personal Name	Date	Lines
1552.1	Unlikely to be a quota problem	WTFN::SCALES	Despair is appropriate and inevitable.	`Wed Jun 04 1997 16:15`	28
	.0> It works when he runs the appln configured for a small number of threads .0> & mutexes, but hangs when he configures it for a large number of threads .0> (~100) and mutexes (~2,100). What makes you think the hang is related to quotas? (E.g., what "state" is the process in when it is hung? COM, LEF, HIB, RWxxx?) Is the kernel support for threads enabled? (I.e., how was the program linked?) .0> It would help in troubleshooting this to know what VMS resource POSIX .0> mutexes are mapped to. They are not "mapped". They are created from scratch out of process address space virtual memory and operated on via atomic hardware instructions. .0> if I do ANALYSE/SYSTEM then SHOW PROC there is a "Mutex count" field: Those are kernel (SMP) mutexes, not POSIX (user mode) mutexes, a completely different animal. You might want to try using the Pthread debugging commands, documented in the "Guide to DECthreads". They should be available in SDA on OpenVMS Alpha V7.1 via SDA> PTHREAD <pthread-debug-command> Webb
1552.2		RDGENG::WOOD_J	John.Wood@reo.dec.com	`Fri Jun 06 1997 07:48`	22
	Thanks for the reply. > What makes you think the hang is related to quotas? Three reasons: 1) the number of mutexes created before hanging was similar to the process's ENQLM limit; 2) the code works on Solaris & HP-UX; and 3) the program works on VMS when configured to use less threads & mutexes. >What "state" is the process in when it is hung COM state. We'll check how the appln was built, etc., as you suggested. Are there any patches which might be relevant to threads on OpenVMS Alpha v7.1? Specifically I found reference to ALPACRT02_071 which fixes some problems with the DEC C RTL re. threads. Thanks, John Wood
1552.3		DCETHD::BUTENHOF	Dave Butenhof, DECthreads	`Fri Jun 06 1997 11:30`	35
	.2> > What makes you think the hang is related to quotas? .2> .2> Three reasons: 1) the number of mutexes created before hanging was .2> similar to the process's ENQLM limit; 2) the code works on .2> Solaris & HP-UX; and 3) the program works on VMS when configured .2> to use less threads & mutexes. What interfaces are you using on Solaris, HP-UX, and OpenVMS? Either they're using an HP-UX 10.30 (or is it 11.0 now?) beta, and POSIX threads on all 3, or they're using DCE threads with a third-party Solaris implementation, or they're using different source code. In any case, the systems are so different that the fact that something happens to run on two out of three means very little. Any similarity between the number of mutexes created and any system quota was, as Webb already implied, purely coincidental. The only quota involved in mutex creation is process virtual memory (page limit, swap limit, swap file size, etc.) .2> >What "state" is the process in when it is hung .2> .2> COM state. Try the SDA (analyze/system) commands "pthread thread -f" and "pthread mutex -wfq" on the process. That will tell us what the threads are doing, and what is being done with the mutexes in the process. .2> We'll check how the appln was built, etc., as you suggested. Check the MULTITHREAD sysgen parameter, and the use of the /THREADS_ENABLE qualifier on LINK. The application should work with or without, but it's important that we know the configuration to diagnose the behavior. /dave