On Tue, 12 Sep 2017 16:36:44 +0200, Charles Mills <[email protected]> wrote:
>Disabling for interruptions is not sufficient in a multi-processor world, >right? > >I don't pretend to be the world's biggest machine instruction expert. Am I >reading the PoOp correctly that a task wishing another task's >CSST to effectively appear to be entirely atomic (from its CPU's point of >view) could achieve that effect by issuing a serialization >instruction (BCR 15,0)? I won't pretend to be an expert, either, but I do not think a serialization operation will make CSST appear fully atomic to other CPUs. Serialization ensures that all operand fetches by other CPUs, and all operand stores by other CPUs, that occurred conceptually before the serializing instruction, will complete before the serializing instruction resumes. But with CSST, the book says: <quote> When an equal comparison occurs, the replacement value is stored at the first-operand location, and the store value is stored at the second-operand location. The fetch of the first operand for purposes of comparison, and the store of the replacement value into the first-operand location, both appear to be a block-concurrent interlocked-update reference as observed by other CPUs. The store of the store value appears to be block-concurrent as observed by other CPUs. </quote> Note that there are 2 block-concurrent operations described. Fetch and store of he comparison and replacement values is one block-concurrent operation. Storing of the store value is a second block-concurrent operation. Further, the book says: <quote> As observed by this CPU and by other CPUs, all fetches appear to occur before all stores, and the store into the first operand appears to occur before the store into the second operand. </quote> Note that it says the store into the first operand will appear to occur before the store into the second operand, but it does NOT say that an observing CPU will see both stores or neither. If both stores are happening, an observer may see: (a) The first store as complete and the second store not done; or (b) Both the first and second stores complete. All that is guaranteed is that the observer will not see the second store complete but the first one not done (if both are being done). The key to understanding this instruction, I think, is the word "footprint" in the description. A footprint, in my former life as a z/OS developer, was most often used to let a recovery routine know what portions of an operation had completed. For example, if you perform (as you suggested earlier) CS, JNE, MVI and your program fails after the CS but before the JNE/MVI your recovery routine will get control. How will it know what the CS did (that is, whether it made a change)? That information may be critical to the determine the actions you need to take for recovery. With CSST, using the footprint, your recovery routine will know for sure what happened during the CSST, and will know what it needs to do. -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
