From - Mon Aug 04 07:27:38 1997 Path: news.mitre.org!blanket.mitre.org!nntprelay.mathworks.com!howland.erols.net!cpk-news-hub1.bbnplanet.com!su-news-hub1.bbnplanet.com!news.bbnplanet.com!news1.digital.com!pa.dec.com!crl.dec.com!lead.zk3.dec.com!zk2nws.zko.dec.com!usenet From: Dave Butenhof Newsgroups: comp.os.vms Subject: Re: DECThread problem Date: Thu, 31 Jul 1997 08:44:34 -0400 Organization: Digital Equipment Corporation Lines: 92 Message-ID: <33E088B2.167E@zko.dec.com> References: <01ILRPQK2IHU9LUYBB@axpc.rdbewss.redstone.army.mil> NNTP-Posting-Host: kalkin.zko.dec.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01Gold (X11; I; OSF1 X4.2 alpha) Gaylon Stockman wrote: > > OS OpenVMS 6.2-1H3 > PMDF v5.1-7 > > I am working with Innosoft (PMDF) and DEC CSC on this, but was wondering > if anyone had any clues or if you have run into something similar. > > PMDF's new version makes use of DECThreads. All seems well except for > their POP3 and IMAP. They have the same system OS and their CMA*.* files > were the same as mine. PMDF has no problem, but we do. I can not run > the POP3 or IMAP program under debug. The following error occurs: > > AXPC-$ r pop3d/debug > %DECthreads bugcheck (version V2.12-296f), terminating execution. > % Running on OpenVMS AXP [OpenVMS V6.2-1H3; AlphaServer 2100A 5/300, 3 cpus, > % 768Mb] > % Reason: Activation of DECthreads attempted after creating TIS mutexes. > % See 'cma_dump.log' for state information. > %SYSTEM-F-ABORT, abort > > The cma_dump.log gives some information - but never having programed useing > threads I am not sure if the content can lend some answers. (The cma_dump.log > file is a 112 lines long.) I will not post for the sake of space. If someone > thinks it may lend some answers - then I will post. No, the dump log won't help any, in this case. > Has anyone seen this ?? Any clues at all ?? Digital provides, in conjunction with threads, a package called "TIS", which stands for "thread independent services". It's a set of functions for synchronization that don't directly depend on the thread library. The result is fairly low-overhead operation when the code runs in a non-threaded process (just a call and return). When the thread library initializes, however, it dynamically "takes over" all of the TIS functions, so that they become real thread synchronization operations. Thus, a library that wants to be thread-safe without depending on, or creating, threads, uses TIS instead of direct thread library calls. The DEC C library, for example, does this. (At least if you have a sufficiently recent DEC C runtime -- early versions dynamically activated the thread library.) For a number of reasons, however, the "stub" TIS functions to create synchronization objects prior to OpenVMS 7.0 ("stubs" are the non-thread-safe versions used prior to takeover by the thread library) weren't "real" synchronization objects. In fact, using a TIS stub to create a mutex really just incremented a counter, and didn't actually create anything at all. As a result, if the thread library initialized later, that TIS "mutex" wouldn't be usable. That's a pretty dangerous situation, so when the thread initialization detected (via the TIS counters) that a synchronization object had already been created, it failed in the manner you describe. This could only happen if either 1) The application was not linked with the thread library, but threads (CMA$RTL) was dynamically loaded later on (by calling "LFIS", the LIB$FIND_IMAGE_SYMBOL routine). 2) Some shared library had a LIB$INITIALIZE psect that creates a TIS mutex and was invoked BEFORE the CMA$RTL initialize routine. (This would have to be a library on which CMA$RTL was "dependent"... i.e., lower in the link dependency hierarchy -- for example, if you've replaced DECC$SHR, or LIBRTL, or something like that.) 3) Some other unusual scenerio I'm overlooking ;-) The solution is: don't do that! Of course, because at thread initialization time we've got only a counter to indicate that a mutex was created, we can't even do a better job of identifying the source of the problem. And, unless you're actually hitting dynamic loading of CMA$RTL, you can't even debug it, since the debugger doesn't kick in until after LIB$INITIALIZE code is long gone. (You can find out, though, with a simple test... if the error doesn't occur before you get the debugger prompt, then you're somehow dynamically activating the library!) With OpenVMS 7.0, we've upgraded DECthreads to implement the final POSIX 1003.1-1996 pthread interface. One of the nice changes is "static initialization" -- instead of calling a dynamic init routine, you can statically initialize your variables at compile-time. That made it relatively easy for us to resolve this old difficulty. A TIS mutex is now a real mutex (and a TIS condition variable is now a real condition variable), so the bugcheck condition no longer exists. A synchronization object created prior to thread initialization is just as real, and valid, as one created afterwards. /---------------------------[ Dave Butenhof ]--------------------------\ | Digital Equipment Corporation butenhof@zko.dec.com | | 110 Spit Brook Rd ZKO2-3/Q18 http://members.aol.com/drbutenhof | | Nashua NH 03062-2698 http://www.awl.com/cp/butenhof/posix.html | \-----------------[ Better Living Through Concurrency ]----------------/