On 9/12/2017 9:35 AM, Charles Mills wrote:
Disabling for interruptions is not sufficient in a multi-processor world, right?
Disabling for interrupts guarantees, even in a multi-processing world, that the executing unit of work will not lose control from the perspective of the logical CP that is executing under *most* cases. Disablement does not, at least as implemented/defined by MVS, include disabling for machine checks. The cost of disabling and enabling is fairly costly, as well, and limited to supervisor state code, where you can guarantee that all data can be referenced without any resolvable program checks. A lot of constraints... and the possibility exists in a virtualized world that the logical CP could lose control of the physical CP between two instructions even while disabled.
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)?
Again, the intent is *not* for CSST to effectively appear to be entirely atomic. Because it may not. It is to guarantee that either the compare-and-swap and the footprint updates *both* occur (with or without being interrupted), or neither of the updates occur. And it works for problem program state requestors.
What about interrupts to the observing task? Suppose it were re-dispatched on a different CPU after the BCR and before observing storage?
The observing task gets what it gets, and being (or not being) re-dispatched would not be significant.
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
