My multithreaded applications are too simple to encounter this problem. I wonder though, to bypass your problem, if stepping back in time to before multithreading was around would be useful. In those days if you wanted to execute multiple threads, you put each thread in a separate virtual machine and used VMCF or IUCV to pass data and co-ordinate processing. Just a thought.
Peter -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Gary M. Dennis Sent: October 18, 2008 19:24 To: [email protected] Subject: VM Virtual CPUs and Threaded CMS Applications If you do not have experience with threaded CMS application development, I suggest you read anything but the balance of of this email. I have an application that runs under CMS and consists of three distinct layers. 1. The top layer is some virtualized x86 OS. 2. The middle layer performs x86 to z translation 3. The base layer is everything else. That includes code fragment storage, aging, retrieval, statistics collection/ push using IUCV, etc. Layer two has been developed in such a way that, without layer three, it simply translates a code fragments to z architecture code, executes that code, then discards the translated fragment. It detects the interface stub for layer three and, if that is present, it takes advantage of the capabilities including prior translation reuse. Layer 3 is multithreaded and is the cause/source of the problem. Whether layer 3 is run with layers 1 and 2 or in standalone test mode the results are the same. First the environment: VM 4.3 Number of processors: 2 Virtual CPUs (from 2 to 6 .. See note below) Now the application from 10,000 feet: Layer three consists of a parent thread that creates 4 additional threads. Each thread is created in a dispatch class that is unique. Routines are not shared between threads. Upon entry into each routine, the preamble is destroyed and restored on exit to trap any potential inadvertent share. Critical fields shared between threads are protected by a compare and swap spin lock. Part of the testing consists of pushing 1WAY IUCV messages from each connected client every 20 milliseconds. The VM directory for each of 4 machines (one server and three clients) defines the machine as an XC mode machine with: CPU 00 BASE CPU 01 As each thread is created it requests either BASE or ANY CPU affinity. BASE affinity is reserved for the parent and IUCV message handler threads . ANY is used for all other threads . Each affinity request receives a normal return code. All this works beautifully for days and millions of messages UNTIL the number of virtual CPUs defined exceed the number of real CPUs assigned to the VM image. When this takes place, everything comes unstuck. By everything I mean everything in CMS. Stack overflow (03FF abend), free storage management failure, all of it. The multitasking application dev guide states that to the extent possible, dispatch classes are assigned to vCPUs and further states that the max number of vCPUs that may be utilized is equal to the number of dispatch classes. Whether the vCPUs are defined in the user directory entry OR they are created dynamically using the CPU Create CMS function, the results are the same. My questions) 1. Has anyone had a similar experience? 2. Is this a known issue with 4.3? Or in more current releases? 3. Although this seems to be telling me no to go there, I've tried but cannot find anything that says "You'll shoot your eye out , kid." if you define more virtual CPUs than real processors. Anyone know of such a restriction? 4. Is it possible that CMS kernel services don't tolerate a situation where the number of virtual CPUs exceeds "real" processors? Thanks in advance for any insight you might have on this behavior. --. .- .-. -.-- Gary Dennis Mantissa Corporation The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner.
