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.
Doe
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 a
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
fore' 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.
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 footpri
Ah. Got it. Thanks.
CharlesSent from a mobile; please excuse the brevity.
Original message From: Walt Farrell
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 wrote:
>> Not
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 t
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
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 wrote:
>Disabling for interruptions is not sufficient in a multi-processor world,
>right?
>
>I don't pretend to be the wor
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 effe
rame 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-swa
--
:>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
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
, 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 t
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
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 th
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
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."
:>I
18 matches
Mail list logo
