The original problem with MP was lock processing, usually in the nucleus. Some locks are exclusive and the response of a processor that needed the exclusive lock but could not get it was to spin, i.e. execute CS or CDS in tight loop until it obtained the lock.
The response of system software designers to this problem was to have distributed locks so that multiple processors could be doing "system" work at the same time. The other response was to take subsystems, such as JES CICS DB2 IMS and make them use multiple tasks, each of which might be dispatched on a different CP simultaneously. Also by limiting their access to system services (via SVC's), they might minimize their use of global locks. E.g., replace GETMAIN with a local cell/heap strategy. Note that this implies that as long as one is in problem state, one can sail merrily along oblivious to what is going on on other CP's. When I was a developer on a session manager named TPX (10 yrs ago), we used many tasks. Each "file" had its own task (file server). Each service such as signon had a task. Much mainline processing took place in SRB's which can be independently dispatched. Other took place in "main" task. The number of those was a parmeter whose recommended value was twice the number of CP's. I have read dumps where back then we were simultaneously being dispatch on 5 or more processors. What I think IBM is saying is that it is possible to develop software that uses a control strategy of accessing shared resources in way that uses increasing numbers of CP's. pup Doug Fuerst <[EMAIL PROTECTED]> 7/27/2005 12:27 PM I agree, I just don't know. But wouldn't the MPP folks have to have beaten the inter-CPU overhead thing? All MVS performance classes inferred that there was a limit to the efficiency of adding another processor, but I now assume it must only be an MVS limitation. In reality, we are debating the 16 processor to 54 processor question, the scientific people are building these 512 or 1024 processor complexes based sometimes on Intel Pentiums. >Doug >snip>>>>> > >Good point but I am not sure the MPP(s) have the same architecture of the >s/370-s/390's though. I don't know enough about them to really comment >other than what I was told (second hand information). The comparison >might/might not be valid. > >Ed ----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
