The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Paul Gilmartin) writes: > I have believed, and other updates to this thread appear to concur, > that WAIT/POST are older than CS. At some time, then, WAIT/POST > code must have used some other locking mechanism. So, after CS > first became available there may have been some interval before it > was reliable to use CS to bypass POST. When did that interim > conclude, making it safe to bypass POST in that fashion? And might > there be open-source archival MVS (3.8 or earlier) that could > execute on emulated hardware supporting CS, but for which POST > requires the actual SVC? re: http://www.garlic.com/~lynn/2008b.html#31 How does ATTACH pass address of ECB to child? http://www.garlic.com/~lynn/2008b.html#47 How does ATTACH pass address of ECB to child? http://www.garlic.com/~lynn/2008b.html#48 How does ATTACH pass address of ECB to child? http://www.garlic.com/~lynn/2008b.html#50 How does ATTACH pass address of ECB to child? http://www.garlic.com/~lynn/2008b.html#51 How does ATTACH pass address of ECB to child? wait/post was svc into the kernel running disabled for interrupts ... and therefor would be "serialized" from the standpoint of other events. the state of the multiprocessing art when charlie was working on fine-grain multiprocessor locking for cp67 (and invented compare&swap instruction) ... was single supervisor/kernel "spin-lock" ... i.e. a single kernel variable that all first level interrupts handlers would perform a "test&set" on initial entry. if the test&set was succesful, execution would continue thru the first level interrupt handler and into the rest of the kernel. if test&set was unsuccesful, the code would continue to branch back to the test&set instruction until succesful. on leaving the kernel (for application/problem execution), the global kernel spin-lock would be cleared to zeros (allowing other processors to execute in the kernel). implicit was that all wait/post operations were correctly serialized ... along with effectively all other kernel functions ... by combination of the kernel running disabled for interrupts ... and, on real multiprocessor, test&set serialization on the global kernel spin-lock. as noted, with other organizations believing that test&set was adequate for all multiprocessor functions ... the challenge given the science center http://www.garlic.com/~lynn/subtopic.html#545tech was to come up with compare&swap uses that weren't multiprocessor specific. the result was the stuff that appears in the appendex of the principles of opertion ... previous reference http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/A.6?DT=20040504121320 where it was possible to implement correct, concurrent shared operations w/o requiring the overhead of kernel/supervisor calls (which achieved correctly serialized operation, in part by running disabled for asynchronous interrupts). other past posts mentioning various multiprocessor and/or compare&swap interrupt http://www.garlic.com/~lynn/subtopic.html#smp ---------------------------------------------------------------------- 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
