While all of that is interesting, and useful in its own right, none of that matters when a you want to perform a simple atomic "test and set" of a the posted bit in an ECB. Both instructions are atomic for this purpose.
You're not going to have any threading problems when using either instruction to check/set the bit in an ECB. The only reason to stay away from TS when posting is if you also want to update the completion code. And the atomic nature only matters when setting the posted bit. For the task preparing to wait, since it's only a check of the posted bit, you perform a TM and then call WAIT if the posted bit hasn't been set by the time of the TM. David Logan -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Anne & Lynn Wheeler Sent: Sunday, January 20, 2008 11:57 AM To: [email protected] Subject: Re: How does ATTACH pass address of ECB to child? 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] (David Logan) writes: > Test and set works just fine too. They are both atomic. 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? the issue with atomic test&set was that it was a purely binary value ... locked or not locked. charlie was working on fine-grain cp67 multiprocessing locking at the science center (virtual machine operating system running on 360/67) http://www.garlic.com/~lynn/subtopic.html#545tech when he invented compare&swap (as previously noted, CAS was chosen because it is charlie's initials). http://www.garlic.com/~lynn/subtopic.html#smp compare&swap ... allowed for full word binary value ... as opposed to simple set/notset (or locked/notlocked) ... and compare-double&swap allowed for double word value atomic update. in the multithreaded/multiprogramming value ... compare&swap allowed for atomic updating of a wide variety of values. the test&set scenario allowed for "locking" a section of code, non-atomic update of value within the locked code section ... and then unlocking the code section. independent executing paths would arrive at the locked code section and "spin" until the other executable path had released the lock. the problem in the multiprogramming/multithreaded sequence ... is that the executable thread could be interrupted while doing the non-atomic update (but still holding the lock) ... with execution then passing to another thread which went into unending "spin-loop" (waiting for the suspended thread to release the lock). as noted in the examples added to the principles of operation was examples of atomic updates of more complex values (than simple set/not-set) ... which could be used even in interruptable code. prior to compare&swap ... such multiprogramming/multithreaded operation always required the overhead of supervisor call (for performing non-atomic updates in non-interruptable code ... and avoiding possible application spin loops). from long ago and far away A.6 Multiprogramming and Multiprocessing Examples http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/A.6?SHEL F=DZ9ZBK03&DT=20040504121320 for other topic drift ... it has now been 40yrs since three people from the science center came out and installed cp67 at the university. ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
