Discussion:
CSST question
Add Reply
Charles Mills
2017-09-10 16:39:04 UTC
Reply
Permalink
Raw Message
The description of CSST in the PoOp says "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."

Is that saying that there is a chance that another CPU might observe a
condition in which the store of the first operand had occurred, but the
store of the second operand had not? My understanding from earlier
paragraphs was that CSST happened "all at once" from the point of view of
other CPUs. Was I mistaken?

Charles

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Binyamin Dissen
2017-09-10 22:10:54 UTC
Reply
Permalink
Raw Message
On Sun, 10 Sep 2017 09:40:09 -0700 Charles Mills <***@MCN.ORG> wrote:

:>The description of CSST in the PoOp says "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."

:>Is that saying that there is a chance that another CPU might observe a
:>condition in which the store of the first operand had occurred, but the
:>store of the second operand had not? My understanding from earlier
:>paragraphs was that CSST happened "all at once" from the point of view of
:>other CPUs. Was I mistaken?

Perhaps if the CSST works on two adjacent fullwords while the other CPU does a
block concurrent doubleword load?

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David W Noon
2017-09-10 22:55:12 UTC
Reply
Permalink
Raw Message
On Sun, 10 Sep 2017 09:40:09 -0700, Charles Mills (***@MCN.ORG)
wrote about "CSST question" (in <0b3a01d32a53$776116a0$662343e0$@mcn.org>):

[snip]
Post by Charles Mills
Is that saying that there is a chance that another CPU might observe a
condition in which the store of the first operand had occurred, but the
store of the second operand had not? My understanding from earlier
paragraphs was that CSST happened "all at once" from the point of view of
other CPUs. Was I mistaken?
My reading of PoOps is that CSST is guaranteed to be atomic, just like
the other instructions in the compare-and-swap family. So your first
understanding is correct.
--
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
***@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Binyamin Dissen
2017-09-11 09:11:53 UTC
Reply
Permalink
Raw Message
On Sun, 10 Sep 2017 23:56:21 +0100 David W Noon
<0000013a910fd252-dmarc-***@LISTSERV.UA.EDU> wrote:

:>On Sun, 10 Sep 2017 09:40:09 -0700, Charles Mills (***@MCN.ORG)
:>wrote about "CSST question" (in <0b3a01d32a53$776116a0$662343e0$@mcn.org>):

:>> Is that saying that there is a chance that another CPU might observe a
:>> condition in which the store of the first operand had occurred, but the
:>> store of the second operand had not? My understanding from earlier
:>> paragraphs was that CSST happened "all at once" from the point of view of
:>> other CPUs. Was I mistaken?

:>My reading of PoOps is that CSST is guaranteed to be atomic, just like
:>the other instructions in the compare-and-swap family. So your first
:>understanding is correct.

My understanding is only block-concurrent operations are seen as atomic by
other processors, i.e., if one CPU is storing a fullword while another CPU is
fetching it, the results of the fetch will be either the original value or the
new value but never a combination of some bits/bytes or the original and some
bits/bytes of the new. Same with two processes storing - the result will be
either the value from CPUA or the value from CPUB - never a combination.

As CSST works on separate "blocks" I don't see how this is possible.

I don't know if channels are block concurrent or not.

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Greg Dyck
2017-09-11 12:52:42 UTC
Reply
Permalink
Raw Message
On 9/10/2017 11:39 AM, Charles Mills wrote:
...
Post by Charles Mills
Is that saying that there is a chance that another CPU might observe a
condition in which the store of the first operand had occurred, but the
store of the second operand had not? My understanding from earlier
paragraphs was that CSST happened "all at once" from the point of view of
other CPUs. Was I mistaken?
Yes, it is saying that another CPU *might* observe the first store but
not the second. As I read it, the POPs does *not* say that say CSST
happens "all at once." It says that any fetches occur before a store
occurs, and that each stores is block concurrent. If the compare is
successful the processor will perform both stores. If the compare fails
the processor will *not* perform both stores.

The following from the POPs is important to consider with respect to
usage of CSST-

3. The store value is intended to provide a separate
“footprint” of the interlocked-update operation in
a location apart from the first operand in a single
unit of operation.

The store into the second operand is a "footprint". CSST was not
intended to be used as a means to atomically update two disparate
storage locations. Rather, as a way to perform a Compare-and-swap
operation, and set a footprint for recovery (ie, the CS completed) in
non-shared storage associated with the current unit of work.

Regards, Greg

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-09-12 05:43:52 UTC
Reply
Permalink
Raw Message
Not arguing at all, but what then is the point of CSST? What does CSST accomplish that could not more easily be done with CS/JNE/MVI or Store?

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Greg Dyck
Sent: Monday, September 11, 2017 2:54 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: CSST question

On 9/10/2017 11:39 AM, Charles Mills wrote:
...
Post by Charles Mills
Is that saying that there is a chance that another CPU might observe a
condition in which the store of the first operand had occurred, but
the store of the second operand had not? My understanding from earlier
paragraphs was that CSST happened "all at once" from the point of view
of other CPUs. Was I mistaken?
Yes, it is saying that another CPU *might* observe the first store but not the second. As I read it, the POPs does *not* say that say CSST happens "all at once." It says that any fetches occur before a store occurs, and that each stores is block concurrent. If the compare is successful the processor will perform both stores. If the compare fails the processor will *not* perform both stores.

The following from the POPs is important to consider with respect to usage of CSST-

3. The store value is intended to provide a separate
“footprint” of the interlocked-update operation in
a location apart from the first operand in a single
unit of operation.

The store into the second operand is a "footprint". CSST was not intended to be used as a means to atomically update two disparate storage locations. Rather, as a way to perform a Compare-and-swap operation, and set a footprint for recovery (ie, the CS completed) in non-shared storage associated with the current unit of work.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2017-09-12 12:04:36 UTC
Reply
Permalink
Raw Message
That is covered in Programming Note #5: "[CSST] should only be used
when an interruption between the compare-and-swap operation and the
store operation cannot be tolerated, and other means of disabling for
interruptions are not practical."

Per Programming Note #4, there's no other reason to use it: "The
performance of [CSST] may be significantly slower than the that of
separate [CS, BC, and ST] instructions."

How such a situation develops, I don't know, but evidently it did somewhere.

sas
Post by Charles Mills
Not arguing at all, but what then is the point of CSST? What does CSST accomplish that could not more easily be done with CS/JNE/MVI or Store?
Charles
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-09-12 14:35:50 UTC
Reply
Permalink
Raw Message
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)?

What about interrupts to the observing task? Suppose it were re-dispatched on a different CPU after the BCR and before observing storage?

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Steve Smith
Sent: Tuesday, September 12, 2017 2:06 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: CSST question

That is covered in Programming Note #5: "[CSST] should only be used when an interruption between the compare-and-swap operation and the store operation cannot be tolerated, and other means of disabling for interruptions are not practical."

Per Programming Note #4, there's no other reason to use it: "The performance of [CSST] may be significantly slower than the that of separate [CS, BC, and ST] instructions."

How such a situation develops, I don't know, but evidently it did somewhere.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Greg Dyck
2017-09-13 19:19:02 UTC
Reply
Permalink
Raw Message
Post by Charles Mills
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.
Post by Charles Mills
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.
Post by Charles Mills
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Binyamin Dissen
2017-09-12 12:13:10 UTC
Reply
Permalink
Raw Message
If the following store would cause an abend?

On Tue, 12 Sep 2017 07:44:58 +0200 Charles Mills <***@MCN.ORG> wrote:

:>Not arguing at all, but what then is the point of CSST? What does CSST accomplish that could not more easily be done with CS/JNE/MVI or Store?

:>Charles

:>-----Original Message-----
:>From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Greg Dyck
:>Sent: Monday, September 11, 2017 2:54 PM
:>To: IBM-***@LISTSERV.UA.EDU
:>Subject: Re: CSST question

:>On 9/10/2017 11:39 AM, Charles Mills wrote:
...
:>> Is that saying that there is a chance that another CPU might observe a
:>> condition in which the store of the first operand had occurred, but
:>> the store of the second operand had not? My understanding from earlier
:>> paragraphs was that CSST happened "all at once" from the point of view
:>> of other CPUs. Was I mistaken?

:>Yes, it is saying that another CPU *might* observe the first store but not the second. As I read it, the POPs does *not* say that say CSST happens "all at once." It says that any fetches occur before a store occurs, and that each stores is block concurrent. If the compare is successful the processor will perform both stores. If the compare fails the processor will *not* perform both stores.

:>The following from the POPs is important to consider with respect to usage of CSST-

:> 3. The store value is intended to provide a separate
:> “footprint” of the interlocked-update operation in
:> a location apart from the first operand in a single
:> unit of operation.

:>The store into the second operand is a "footprint". CSST was not intended to be used as a means to atomically update two disparate storage locations. Rather, as a way to perform a Compare-and-swap operation, and set a footprint for recovery (ie, the CS completed) in non-shared storage associated with the current unit of work.

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2017-09-12 15:06:29 UTC
Reply
Permalink
Raw Message
Post by Charles Mills
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-09-13 09:01:26 UTC
Reply
Permalink
Raw Message
Post by Walt Farrell
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.
Again, not arguing, just trying to fully understand. In your answer above, did you consider this sentence from the PoOp description?

"A serialization function is performed before the operation begins and again after the operation is completed."

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Walt Farrell
Sent: Tuesday, September 12, 2017 5:08 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: CSST question
Post by Walt Farrell
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.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Binyamin Dissen
2017-09-13 10:07:30 UTC
Reply
Permalink
Raw Message
On Wed, 13 Sep 2017 11:02:25 +0200 Charles Mills <***@MCN.ORG> wrote:

:>> 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.

:>Again, not arguing, just trying to fully understand. In your answer above, did you consider this sentence from the PoOp description?

:>"A serialization function is performed before the operation begins and again after the operation is completed."

I suggest that you read the "CPU Serialization" in the POPs. It doesn't work
the way that you think.

:>-----Original Message-----
:>From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Walt Farrell
:>Sent: Tuesday, September 12, 2017 5:08 PM
:>To: IBM-***@LISTSERV.UA.EDU
:>Subject: Re: CSST question
:>
:>On Tue, 12 Sep 2017 16:36:44 +0200, Charles Mills <***@MCN.ORG> 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.
:>
:>----------------------------------------------------------------------
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2017-09-13 13:57:50 UTC
Reply
Permalink
Raw Message
Post by Charles Mills
Post by Walt Farrell
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.
Again, not arguing, just trying to fully understand. In your answer above, did you consider this sentence from the PoOp description?
"A serialization function is performed before the operation begins and again after the operation is completed."
Yes, I did. But as Binyamin says, you need to understand what CPU serialization entails.

Again, I'm not an expert, but this is my interpretation: When you do something that serializes, the CPU ensures that all fetches and stores that have conceptually _completed_ by other CPUs are actually complete before you proceed. But CSST has two block-concurrent operations with a tiny window between the first store and the second store. Therefore, if a CSST occurs on a different CPU in theory your serialization coulde occur between the first and second store operations, and your serialization could complete and allow you to see the result of the first but not the second operation.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-09-13 14:26:32 UTC
Reply
Permalink
Raw Message
Ah. Got it. Thanks.



CharlesSent from a mobile; please excuse the brevity.
Post by Charles Mills
Post by Walt Farrell
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.
Again, not arguing, just trying to fully understand. In your answer above, did you consider this sentence from the PoOp description?
"A serialization function is performed before the operation begins and again after the operation is completed."
Yes, I did. But as Binyamin says, you need to understand what CPU serialization entails.

Again, I'm not an expert, but this is my interpretation: When you do something that serializes, the CPU ensures that all fetches and stores that have conceptually _completed_ by other CPUs are actually complete before you proceed. But CSST has two block-concurrent operations with a tiny window between the first store and the second store. Therefore, if a CSST occurs on a different CPU in theory your serialization coulde occur between the first and second store operations, and your serialization could complete and allow you to see the result of the first but not the second operation.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-09-13 14:32:11 UTC
Reply
Permalink
Raw Message
I thought Greg Dyck's post perfectly answered the what's and why's,
including the sole reason for which the instruction was created.

Disablement for external and I/O interrupts prevents the work unit from
being undispatched in between the serialized operation and the store that
sets the footprint.
CSST accomplishes that by combining the two into one instruction. Not
having to disable is of course simpler and also makes this function
available to problem state programs (since they cannot disable).

One might ask "if you were disabled for external and I/O interrupts, could
LPAR undispatch you from the processor in between the serialized operation
and the store?". The answer must be "yes", but this would not be visible
to the work unit. As far as z/OS was concerned, the work unit would still
be dispatched.

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-09-13 17:26:11 UTC
Reply
Permalink
Raw Message
@Peter, thank you.

Assume that code in question were to issue a CSST that successfully swapped
POINTER and stored a value at ADDRESS.

Question: is there any way for the 'examining' code, possibly running on a
different CPU, to be assured of seeing a consistent (either 'before' or
'after') POINTER and ADDRESS contents? Possibly with serialization at some
point?

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Wednesday, September 13, 2017 4:33 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: CSST question

I thought Greg Dyck's post perfectly answered the what's and why's,
including the sole reason for which the instruction was created.

Disablement for external and I/O interrupts prevents the work unit from
being undispatched in between the serialized operation and the store that
sets the footprint.
CSST accomplishes that by combining the two into one instruction. Not having
to disable is of course simpler and also makes this function available to
problem state programs (since they cannot disable).

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Greg Dyck
2017-09-13 19:27:12 UTC
Reply
Permalink
Raw Message
Post by Charles Mills
Question: is there any way for the 'examining' code, possibly running on a
different CPU, to be assured of seeing a consistent (either 'before' or
'after') POINTER and ADDRESS contents? Possibly with serialization at some
point?
In general, no.

The architecture only guarantees storage consistency if the data is in
the same double word, aligned on a double word boundary, in the general
case (such as using LM or STM) or the same quad word, aligned on a quad
word boundary, for a defined set of instructions (such as CDSG).

Regards,
Greg

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2017-09-13 19:55:51 UTC
Reply
Permalink
Raw Message
Post by Walt Farrell
Again, I'm not an expert, but this is my interpretation: When you
do something that serializes, the CPU ensures that all fetches and
stores that have conceptually _completed_ by other CPUs are
actually complete before you proceed.
Does it? I read it differently. The way I read it is that all fetches and
stores (and some other things) that have conceptually completed by
_this_ CPU are actually complete before you proceed.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...