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: > 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. the original post http://www.garlic.com/~lynn/2008b.html#31 How does ATTACH pass address of ECB to child was about quote from the principles of operation with regard to the example of post routine bypass: A.6.3.1 Bypass Post Routine http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/A.6.3.1?SHELF=DZ9ZBK03&DT=20040504121320&CASE= from above: The following routine allows the SVC "POST" as used in MVS/ESA to be bypassed whenever the corresponding WAIT has not yet been executed, provided that the supervisor WAIT and POST routines use COMPARE AND SWAP to manipulate event control blocks (ECBs). ... snip ... somebody then noted the caveate about supervisor WAIT & POST routines using COMPARE AND SWAP ... and I replied that the original writeup was over 35 yrs ago ... back to when the pok favorite son operating system assumed that test&set was more than adequate for all purposes. http://www.garlic.com/~lynn/2008b.html#47 How does ATTACH pass address of ECB to child (atomic) test&set http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/7.5.139?SHELF=DZ9ZBK03&DT=20040504121320 from above: The leftmost bit (bit position 0) of the byte located at the second-operand address is used to set the condition code, and then the byte is set to all ones. ... snip ... has always been defined to test a single bit and if it is zero ... sets the whole byte to ones (x"ff") as well as the corresponding condition code. so the post routine bypass needs to do atomic replace of the whole word (or simulated atomic replace by executing in disabled kernel with code function locking). for topic drift, quick search engine turns up this reference to ECB field, wait, post (and other os simulation services): http://www.agorics.com/Library/KeyKos/Gnosis/190.html from above: SVC 2 - POST POST is fully supported. Bit 0 of the ECB is set to 0, bit 1 is set to 1, and bits 8-31 are set to the specified completion code. ... snip ... recent post referencing gnosis and keykos http://www.garlic.com/~lynn/2008b.html#24 folklore indeed but then a little more searching turns up this reference Synchronizing Tasks (WAIT, POST, and EVENTS Macros) http://publib.boulder.ibm.com/infocenter/zos/v1r9/topic/com.ibm.zos.r9.ieaa600/tasks.htm from above: Figure 42. Event Control Block (ECB) 0 1 2 +---+---+-----------------------------------------------+ | W | P | completion code | +---+---+-----------------------------------------------+ When an ECB is originally created, bits 0 (wait bit) and 1 (post bit) must be set to zero. If an ECB is reused, bits 0 and 1 must be set to zero before a WAIT, EVENTS ECB= or POST macro can be specified. If, however, the bits are set to zero before the ECB has been posted, any task waiting for that ECB to be posted will remain in the wait state. When a WAIT macro is issued, bit 0 of the associated ECB is set to 1. When a POST macro is issued, bit 1 of the associated ECB is set to 1 and bit 0 is set to 0. For an EVENTS type ECB, POST also puts the completed ECB address in the EVENTS table. ... snip ... i.e. initially both bits zero and one are zero. wait specifies that bit zero is set to one. post specifies that bit 0 is set to zero, bit one is set to one, and the rest of the word is filled in with complettion code. test&set checks bit zero for being set to zero and then sets the whole byte to one. ... so discussing the post routine bypass scenario (from the orignal post) ... of a multithreaded operation performing a post operation ... when the "WAIT hasn't yet been executed" (i.e. both bits zero and one are still zero), an atomic replace occurs setting bit 0 to zero, bit 1 to one and the rest of the word to the completion code (as long both bits zero and one are still zero). this is further dependent on the wait routine only doing an atomic setting of bit zero to one ... as long as both bits zero and one are still zero. unfortunately, test&set only tests bit zero for zero ... before setting the whole byte to one. that means that atomic test&set doesn't correctly perform the wait operation if the ECB has already been posted (since test&set is only checking bit zero for zero ... and not both bit zero and bit one). past posts mentioning the science center http://www.garlic.com/~lynn/subtopic.html#545tech and other posts mentioning multiprocessing support and/or compare&swap instruction 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
