The following message is a courtesy copy of an article that has been posted to alt.folklore.computers as well.
[EMAIL PROTECTED] (John P Baker) writes: > Reentrancy may be preferred, but it is not always reasonable or even > possible. Each situation must be evaluated on its own merits. so possibly not just simple reentrancy ... but also thread/multitasking *safe* ... including use of compare&swap semantics slightly related posts from a.f.c. http://www.garlic.com/~lynn/2006s.html#21 Very slow booting and running and brain-dead OS's? http://www.garlic.com/~lynn/2006s.html#40 Ranking of non-IBM mainframe builders? including needing new programming paradigm to leverage parallel thruput on the increasingly multiprocessor machines. http://www.garlic.com/~lynn/2006s.html#19 Very slow booting and running and brain-dead OS's? as i've mentioned before, charlie had been doing a lot of work on multiprocessor fine-grain locking on cp67 kernel at the science center http://www.garlic.com/~lynn/subtopic.html#545tech and invented the compare&swap instruction (original mnemonic chosen because CAS are charlie's initials). initial attempt at getting compare&swap into 370 architecture was rebuffed by the (370 architecture) redbook owners. they effectively said that the mainstream operating system (i.e. os/360 derivatives) were doing just fine in their multiprocessor support carrying over the test&set instruction from 360 (and extremely course-grain locking). the challenge was that to get compare&swap instruction into 370 ... it needed to have uses that were non-multiprocessor specific. thus was born the compare&swap description for multitreaded/multitasking ... originally including in the programming notes for compare&swap ... since moved to the appendix of principles of operation A.6 Multiprogramming and Multiprocessing Examples http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/A.6?SHELF=DZ9ZBK03&DT=20040504121320 from above: When two or more programs sharing common storage locations are being executed concurrently in a multiprogramming or multiprocessing environment, one program may, for example, set a flag bit in the common-storage area for testing by another program. It should be noted that the instructions AND (NI or NC), EXCLUSIVE OR (XI or XC), and OR (OI or OC) could be used to set flag bits in a multiprogramming environment; but the same instructions may cause program logic errors in a multiprocessing configuration where two or more CPUs can fetch, modify, and store data in the same storage locations simultaneously. Subtopics: * A.6.1 Example of a Program Failure Using OR Immediate * A.6.2 Conditional Swapping Instructions (CS, CDS) * A.6.3 Bypassing Post and Wait * A.6.4 Lock/Unlock * A.6.5 Free-Pool Manipulation * A.6.6 PERFORM LOCKED OPERATION (PLO) ... snip ... misc. collected posts related to multiprocessor support http://www.garlic.com/~lynn/subtopic.html#smp and some other recent threads touching on programming techniques (including mention of PLI program that I had written in the early 70s that analyzed 360 assembler listings ... control flow, register useage, etc ... and then attempted to generate higher level program representation) http://www.garlic.com/~lynn/2006e.html#32 transputers again was: The demise of Commodore http://www.garlic.com/~lynn/2006p.html#1 Greatest Software Ever Written? http://www.garlic.com/~lynn/2006p.html#4 Greatest Software Ever Written? http://www.garlic.com/~lynn/2006r.html#24 A Day For Surprises (Astounding Itanium Tricks) http://www.garlic.com/~lynn/2006s.html#27 Why these original FORTRAN quirks? ---------------------------------------------------------------------- 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
