Re: CSST question

[Tom Marchant]

On Wed, 13 Sep 2017 08:59:02 -0500, Walt Farrell wrote:

>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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSST question

[Greg Dyck]

On 9/13/2017 12:26 PM, Charles Mills wrote:

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSST question

[Greg Dyck]

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

Re: CSST question

[Charles Mills]

@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-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Wednesday, September 13, 2017 4:33 PM
To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSST question

[Peter Relson]

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSST question

[Charles Mills]

Ah. Got it. Thanks.



CharlesSent from a mobile; please excuse the brevity.
 Original message From: Walt Farrell <walt.farr...@gmail.com> 
Date: 9/13/17  3:59 PM  (GMT+01:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 
CSST question 
On Wed, 13 Sep 2017 11:02:25 +0200, Charles Mills <charl...@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."

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

Re: CSST question

[Walt Farrell]

On Wed, 13 Sep 2017 11:02:25 +0200, Charles Mills  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."

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSST question

[Binyamin Dissen]

On Wed, 13 Sep 2017 11:02:25 +0200 Charles Mills <charl...@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-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Walt Farrell
:>Sent: Tuesday, September 12, 2017 5:08 PM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: Re: CSST question
:>
:>On Tue, 12 Sep 2017 16:36:44 +0200, Charles Mills <charl...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
Binyamin Dissen <bdis...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSST question

[Charles Mills]

> 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-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Tuesday, September 12, 2017 5:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSST question

On Tue, 12 Sep 2017 16:36:44 +0200, Charles Mills <charl...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSST question

[Walt Farrell]

On Tue, 12 Sep 2017 16:36:44 +0200, Charles Mills  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:

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.


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:

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.


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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSST question

[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)?

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-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Tuesday, September 12, 2017 2:06 PM
To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSST question

[Binyamin Dissen]

If the following store would cause an abend?

On Tue, 12 Sep 2017 07:44:58 +0200 Charles Mills <charl...@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-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Greg Dyck
:>Sent: Monday, September 11, 2017 2:54 PM
:>To: IBM-MAIN@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 <bdis...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSST question

[Steve Smith]

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

On Tue, Sep 12, 2017 at 1:44 AM, Charles Mills  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
>

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

Re: CSST question

[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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Dyck
Sent: Monday, September 11, 2017 2:54 PM
To: IBM-MAIN@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.

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

Re: CSST question

[Greg Dyck]

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.


Regards, Greg

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

Re: CSST question

[Binyamin Dissen]

On Sun, 10 Sep 2017 23:56:21 +0100 David W Noon
<013a910fd252-dmarc-requ...@listserv.ua.edu> wrote:

:>On Sun, 10 Sep 2017 09:40:09 -0700, Charles Mills (charl...@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 
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSST question

[David W Noon]

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

[snip]
> 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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

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

Re: CSST question

[Binyamin Dissen]

On Sun, 10 Sep 2017 09:40:09 -0700 Charles Mills  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 
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN