On Mon, 18 Nov 2013 22:34:57 -0800, Ed Jaffe wrote:
On 11/10/2013 1:19 PM, Mark Zelden wrote:
I've not been paying that close of attention, but I'm more curious
about what people did for these situations prior to PLO.
ENQ/DEQ or Latch
I can still vividly remember first reading PLO in the
-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Shane Ginnane
Sent: 19 November 2013 09:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
On Mon, 18 Nov 2013 22:34:57 -0800, Ed Jaffe wrote:
On 11/10/2013 1:19 PM, Mark Zelden wrote
Long-winded and ugly but functionally adequate serialization machinery
can be developed using TS alone
PLO is convenient and should be more perspicuous; but this thread and
several related predecessors strongly suggest that more often it is
caviar to the general.
John Gilmore, Ashland, MA 01721
jwgli...@gmail.com (John Gilmore) writes:
Long-winded and ugly but functionally adequate serialization machinery
can be developed using TS alone
that was the argument that the POK favorite son operating system people
used when attempt was made to add comapre-and-swap to 370.
charlie had
Wheeler [l...@garlic.com]
Sent: 19 November 2013 16:49
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
charlie had invented compare-and-swap while doing fine grain
multiprocessing locking for cp67 at the cambridge science center
It is always hard to make oneself understood in emotion-laden
situations, but I did try. I prefaced my comment about the logical
adequacy of TS with the words
Long-winded and ugly . . .
Perhaps an analogy will help. Boolean algebra is usually discussed
using the binary operations disjunction
In
CAE1XxDGQkTVXZVP3fD-4=jv1ufzxijwt8_dxmrvw+gra6tn...@mail.gmail.com,
on 11/19/2013
at 07:29 AM, John Gilmore jwgli...@gmail.com said:
Long-winded and ugly but functionally adequate serialization
machinery can be developed using TS alone
Turing Tar Pit: the situation where everything is
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
John Gilmore [jwgli...@gmail.com]
Sent: 19 November 2013 19:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
Perhaps an analogy will help. Boolean algebra is usually discussed
On 11/10/2013 1:19 PM, Mark Zelden wrote:
I've not been paying that close of attention, but I'm more curious
about what people did for these situations prior to PLO.
ENQ/DEQ or Latch
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
On 13/11/2013 12:34 PM, Kenneth Wilkerson wrote:
Actually, the algorithm performs well for read-often, write-rarely
list because the active chain count does not change and therefore
there are relatively infrequent re-drives
Subject: Re: Serialization without Enque
On 14/11/2013 12:23 AM, Kenneth Wilkerson wrote:
If I read the article you sent correctly, this algorithm is using a
spin lock. It has provision for implementing a lock-free algorithm but
none of those are detailed.
Most of the shared_ptr implementations
http://www.techdirt.com/articles/20130723/09543223903/joel-spolsky-stackexchange-thwarts-broad-microsoft-patent-app-using-microsofts-own-prior-art.shtml
Submit Prior Art to U.S. Patent office Appilications
http://patents.stackexchange.com/
On Thu, Nov 14, 2013 at 7:19 AM, Kenneth Wilkerson
In 5284c4bc.5000...@gmail.com, on 11/14/2013
at 08:40 PM, David Crayford dcrayf...@gmail.com said:
Or patents! I notice IBM have quite a few wrt PLO.
Could they be defensive patents? The only really effective way to
prevent someone else from patenting a technique that you're using is
to file
On 14 November 2013 09:26, Shmuel Metz (Seymour J.)
shmuel+ibm-m...@patriot.net wrote:
at 08:40 PM, David Crayford dcrayf...@gmail.com said:
Or patents! I notice IBM have quite a few wrt PLO.
Could they be defensive patents? The only really effective way to
prevent someone else from
In
CAArMM9S8B0_nTv3XiVPv1JLtw2=HfMH5m7sNCFFo6Kd4=mAA=g...@mail.gmail.com,
on 11/14/2013
at 03:26 PM, Tony Harminc t...@harminc.net said:
If you don't want to patent, but also don't want others to patent
your invention, you can publish in a place that gets reasonable
exposure,
The point of a
In 001801cee029$af0d2bc0$0d278340$@austin.rr.com, on 11/12/2013
at 10:34 PM, Kenneth Wilkerson redb...@austin.rr.com said:
Actually, the algorithm performs well for read-often, write-rarely
list because the active chain count does not change and therefore
there are relatively infrequent
the high or low word.
Kenneth
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Shmuel Metz (Seymour J.)
Sent: Wednesday, November 13, 2013 7:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
In 001801cee029$af0d2bc0
Sent: Tuesday, November 12, 2013 11:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
On 13/11/2013 12:34 PM, Kenneth Wilkerson wrote:
Actually, the algorithm performs well for read-often, write-rarely
list because the active chain count does not change and therefore
Let's begin with queue-handling 101. A queue is a FIFO list. One
adds elements to the rear of a queue and removes them from the front.
Tony Harminc's implicit point, that these two operations can be
serialized and done unproblematically, is correct beyond argument.
There is never a requirement
is an option because it
could be a significant amount of storage.
Thanks, Jon Perryman.
From: Tony Harminc t...@harminc.net
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, November 11, 2013 7:07 PM
Subject: Re: Serialization without Enque
On 11 November 2013 20:15, Jon
In 1384218943.19861.yahoomail...@web181001.mail.ne1.yahoo.com, on
11/11/2013
at 05:15 PM, Jon Perryman jperr...@pacbell.net said:
Take for example:
L R2,QUEUE
L R3,NEXT_ENTRY
CS R2,R3,QUEUE New queue head
I'm not sure what you're trying to do. Did you
Thanks Kenneth for the explanation. It's really good stuff. All the
serialization that I've seen was prior to the PLO instruction. I now see that
it has certainly improved our ability to serialize.
Jon Perryman.
From: Kenneth Wilkerson redb...@austin.rr.com
The example was simply to show a point without using an involved sample. At a
minimum, I should have included a USING for the queue entry. Sorry for the
confusion.
Jon Perryman.
From: Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net
In
-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
Could you provide an insight to a design that would handle the situation
where an SSI program with non-trivial workload uses a very large list. This
list is normally semi-static but there can be periods of time where entries
are heavily
: Serialization without Enque
Thanks for sharing your design Ken. It seems to me that PLO is best used for
data structures like double-ended queues where elements can be
inserted/removed from both ends of the queue atomically. In the case of a
read-often-write-rarely list with multiple readers
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Tuesday, November 12, 2013 8:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
Thanks for sharing your design Ken. It seems to me that PLO is best used for
data structures like double
What are bakery style ticketing algorithms? Take-a-number schemes?
Googling bakery style landed me among recipes/receipts for
chocolate-chip cookies and cupcakes with pink icing.
John Gilmore, Ashland, MA 01721 - USA
--
For
My control blocks are actually a queue. So it my understanding from reading
these updates (Thank You!) that all I really need is autonomic functions (CS or
PLO) to update the queue.
--
For IBM-MAIN subscribe / signoff / archive
suggests that Hardware Transaction Memory may not be the panacea we all
expect it to be, and in some cases may actually increase CPU
Of course it's true that if a transaction experiences too much contention
and resorts to its fallback path, you have used more CPU than if you went
directly to
In 8451960728331713.wa.markmzelden@listserv.ua.edu, on
11/10/2013
at 03:19 PM, Mark Zelden m...@mzelden.com said:
I've not been paying that close of attention, but I'm more curious
about what people did for these situations prior to PLO.
CS. In some cases PLO can be more natural.
--
On 11 Nov 2013, at 8:22 pm, John Gilmore jwgli...@gmail.com wrote:
What are bakery style ticketing algorithms? Take-a-number schemes?
http://en.m.wikipedia.org/wiki/Lamport's_bakery_algorithm
Googling bakery style landed me among recipes/receipts for
chocolate-chip cookies and cupcakes
Message -
From: David Crayford dcrayf...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, November 11, 2013 7:22:38 AM
Subject: Re: Serialization without Enque
On 11 Nov 2013, at 8:22 pm, John Gilmore jwgli...@gmail.com wrote:
What are bakery style ticketing algorithms? Take
-
From: David Crayford dcrayf...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, November 11, 2013 7:22:38 AM
Subject: Re: Serialization without Enque
On 11 Nov 2013, at 8:22 pm, John Gilmore jwgli...@gmail.com wrote:
What are bakery style ticketing algorithms? Take-a-number schemes
: Serialization without Enque
On 11 Nov 2013, at 8:22 pm, John Gilmore jwgli...@gmail.com wrote:
What are bakery style ticketing algorithms? Take-a-number schemes?
http://en.m.wikipedia.org/wiki/Lamport's_bakery_algorithm
Googling bakery style landed me among recipes/receipts for
chocolate
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of David Crayford
Sent: Sunday, November 10, 2013 8:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
On 11/11/2013 10:36 AM, Kenneth Wilkerson wrote:
I read the article. This article is about transactional
, 2013 7:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
suggests that Hardware Transaction Memory may not be the panacea we all
expect it to be, and in some cases may actually increase CPU
Of course it's true that if a transaction experiences too much contention
Appropriate / safe is in the eye of the beholder. I personally see
serialization as reducing the risks as much as possible. To eliminate the risk,
you would have to orphan the entry. There were recommendations of moving to a
free chain and reusing them. This has risks too because you simply
On 11/11/2013 9:09 PM, Peter Relson wrote:
Maybe it's me, but I don't really find TBEGIN...TEND complex compared to
other serializing techniques even when you factor in PPI while counting
the number of attempts before taking the fallback path. The instructions
within a transaction are typically
On 11 November 2013 20:15, Jon Perryman jperr...@pacbell.net wrote:
LR2,QUEUE
LR3,NEXT_ENTRY
CS R2,R3,QUEUENew queue head
While this seems bullet proof, it's not. If there is a long delay between
between the L instructions then next entry could
because it could be a
significant amount of storage.
Thanks, Jon Perryman.
From: Tony Harminc t...@harminc.net
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, November 11, 2013 7:07 PM
Subject: Re: Serialization without Enque
On 11 November 2013 20:15, Jon Perryman
In
caarmm9qm+goqco6p3nef5jsy1miorusy_c8ajjjoxhpeiry...@mail.gmail.com,
on 11/07/2013
at 08:55 PM, Tony Harminc t...@harminc.net said:
It serializes happily against all the CS variations, TS, and the
newer interlocked-update instructions like ASI, LAA, and so on.
It's a bit more complicated
From time to time Shmuel makes a seminal, crucial contribution; and
begin extract
the point remains that the user of a synchronization facility needs to
understand the rules and should not expect interoperability between
unrelated facilities, e.g., latches and semaphores.
/end extract
is one of
In 20131109.144735.898...@webmail11.dca.untd.com, on 11/09/2013
at 07:47 PM, esst...@juno.com esst...@juno.com said:
It would be nice if someone would actually post some working code
using a PLO instruction,
It would be even nicer if IBM would add some PLO examples to Appendix
A of PoOps.
On Sat, 9 Nov 2013 19:47:35 GMT, esst...@juno.com esst...@juno.com wrote:
I have been reading and following this thread sine PLO is not an instruction I
use every day.
It would be nice if someone would actually post some working code using a PLO
instruction, to illustrate how one would add an
On 11/11/2013 5:19 AM, Mark Zelden wrote:
On Sat, 9 Nov 2013 19:47:35 GMT, esst...@juno.com esst...@juno.com wrote:
I have been reading and following this thread sine PLO is not an instruction I
use every day.
It would be nice if someone would actually post some working code using a PLO
@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
On 11/11/2013 5:19 AM, Mark Zelden wrote:
On Sat, 9 Nov 2013 19:47:35 GMT, esst...@juno.com esst...@juno.com wrote:
I have been reading and following this thread sine PLO is not an instruction
I use every day.
It would be nice
Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of David Crayford
Sent: Sunday, November 10, 2013 6:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
On 11/11/2013 5:19 AM, Mark Zelden wrote:
On Sat, 9 Nov 2013 19:47:35 GMT, esst
I see a flaw in my logic... I need to use PLO to serialize all this time.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
I have been reading and following this thread sine PLO is not an instruction I
use every day.
It would be nice if someone would actually post some working code using a PLO
instruction, to illustrate how one would add an element to a queue and remove
an element from a queue.
Paul D'Angelo
Subject: Serialization without Enque
I have been reading and following this thread sine PLO is not an instruction
I use every day.
It would be nice if someone would actually post some working code using a
PLO instruction, to illustrate how one would add an element to a queue and
remove an element
applicable to 99%+ of all serialization scenarios you encounter
To be frank, you might not have very complex serialization requirements.
Also, using PLO when CS,CSG,CDS,CDSG would do is a significant waste of
cycles. For the cases I have seen within our code, uses of PLO (in the
cases where
not the case,
why bother creating the transactional execution facility?
Kenneth
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Friday, November 08, 2013 8:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without
-Original Message-
From: Kenneth Wilkerson [mailto:redb...@austin.rr.com]
Sent: Friday, November 08, 2013 8:46 AM
To: 'IBM Mainframe Discussion List'
Subject: RE: Serialization without Enque
I really don't see the big deal with an 0c4 in this scenario (should
happen rarely)
You
Thank You for your help (all of you) but Peter's statement below does not make
sense to me (maybe because I don't understand something).
The reason that the free queue protocol needs a sequence number is because
even if the header matches, the values that you need to put into your
new element
This specific paragraph from Peter is about FREE QUEUE PROTOCOL. This is
where elements on your chain are no longer needed. Peter recommends not freeing
the element. Instead, you should use a queue of free elements that you reuse
when you need a new element.
Peter's concern is not the
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
Thank You for your help (all of you) but Peter's statement below does not make
sense to me (maybe because I don't understand something).
The reason that the free queue protocol needs a sequence number is because even
Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jon Perryman
Sent: Friday, November 08, 2013 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
This specific paragraph from Peter is about FREE QUEUE PROTOCOL. This is
where
The storage overlay does not pertain to the PLO. It pertains to the entire
element not being immediately removed from any type of use. Just because you
removed the element from the chain does not mean it's not in use somewhere. You
can't even say how long the element may be in use (e.g. task
Jon Perryman wrote:
begin extract
This is where elements on your chain are no longer needed. Peter
recommends not freeing the element. Instead, you should use a queue of
free elements that you reuse when you need a new , , ,
/end extract
and I have two comments.
First, 'queue of free elements'
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
The storage overlay does not pertain to the PLO. It pertains to the entire
element not being immediately removed from any type of use. Just because you
removed the element from the chain does not mean it's not in use somewhere
Who frees what is always important. In general a list manager should
have no notion and make no assumptions about the structure or
organization of the things it puts into and removes from the list.
I tell my students that they should think of these things as SOTs,
instances of Something Out
I'm guessing that Peter was warning against the situation where you have an
element table rather than a queue. Queues are straight forward because each
entry will only be in use by 1 program at any given time (ownership is always
the task using it). Element tables on the other hand may have
Looks like my impossible with respect to the free queue protocol needed
to be qualified by until PLO came along as long as you have storage to
work with for the PLO parameters.
As was pointed out to me,
PLO CL and PLO DCS can be used to implement the free queue protocol (and
not need the
I was wondering if there was
quad-word consistency as well?
I'm sure there is
I always insure that the primary counter
is in the first double word.
This is not necessary because of the quadword consistency.
Peter Relson
z/OS Core Technology Design
It has taken me this long to mostly understand PLO... I must be slow.
Now that I understand it (mostly) I am pretty sure it will not work for me. My
problem is that a process comes in and removes the control block chain while
another process is suspended and attempting to update the chain. When
, November 07, 2013 8:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
It has taken me this long to mostly understand PLO... I must be slow.
Now that I understand it (mostly) I am pretty sure it will not work for me. My
problem is that a process comes in and removes
On 7 November 2013 09:33, Donald Likens dlik...@infosecinc.com wrote:
Now that I understand it (mostly) I am pretty sure it will not work for me.
My problem is that a process comes in and removes the control block chain
while another process is suspended and attempting to update the chain.
I think I figured out a solution:
DOX078 DS0H
*C IF LASTCB EQ 0 THEN
*C SET LASTCB= FIRSTCB = MSEGCB JUST BUILT
CDS R4,R2,FIRSTCB IF MSEGF MSEGL = 0, STM
If I understand your situation, then you are maintaining a queue. Today, you
are probably queuing in the reverse order using CS (LIFO). You want to
eliminate reversing the queue (FIFO) by using PLO to create the queue FIFO.
PLO is desgned to solve this problem. PLO doesn't care about the store
In
ofe01adb17.e9264150-on85257c1b.0044d053-85257c1b.00455...@us.ibm.com,
on 11/06/2013
at 07:37 AM, Peter Relson rel...@us.ibm.com said:
One of the shortcomings of PLO (unlike TBEGIN(C) ) is that PLO in
general serializes only against other uses of PLO.
I'd hardly label that as a shortcoming
On 6 November 2013 16:30, Shmuel Metz (Seymour J.)
shmuel+ibm-m...@patriot.net wrote:
Peter Relson rel...@us.ibm.com said:
One of the shortcomings of PLO (unlike TBEGIN(C) ) is that PLO in
general serializes only against other uses of PLO.
I'd hardly label that as a shortcoming of PLO.
t...@harminc.net (Tony Harminc) writes:
It serializes happily against all the CS variations, TS, and the newer
interlocked-update instructions like ASI, LAA, and so on. And there
are cases where a simple ST or the like can interoperate usefully with
CS. For instance, if you update a counter
One of the shortcomings of PLO (unlike TBEGIN(C) ) is that PLO in general
serializes only against other uses of PLO. It does not serialize against
CS on the same storage, for example.
However, cache considerations and doubleword consistency still come into
play.
A LM of 2 words of a
as well?
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Wednesday, November 06, 2013 6:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
One of the shortcomings of PLO (unlike TBEGIN(C
Sorry for the confusion but that's not the question that I was asking. I agree
with you on guaranteeing the consistency using the count.
I'm talking about TCB1 using PLO CSDST to store 2 adjacent words (4th 6th PLO
operands) and TCB2 using LM or LG for those same 2 words. There is a very small
, November 05, 2013 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
Sorry for the confusion but that's not the question that I was asking. I
agree with you on guaranteeing the consistency using the count.
I'm talking about TCB1 using PLO CSDST to store 2 adjacent words
PLO CSDST and CSTST are *extremely* useful for queue and linked list
manipulation in multi-ASID multi-TCB environments. The key to their use is to
have a lock word counter that the caller increments and then prepares the new
values in other regs. When it comes time to actually atomically update
On 4/11/2013 4:49 PM, Rob Scott wrote:
I also think the uptake of PLO would be greater if there were some decent
example code in the manuals - for instance a client adding a request to the
tail of the queue whilst a server is removing from the head.
Maybe somebody with expertise should blog
If you truly need a triple compare and swap then PLO will not help you. But if
you need a disjoint double compare and swap, you use the compare-and-swap
field as a counter and then you con do a compare swap and double store.
Example:
Fetch counter
A PLO compare-and-fetch value1
CC0,
PLO CDS does exactly what is wanted.
I presume this was a typo and should have been PLO DCS (double compare and
swap)
PLO CSDST (and CSST and CSTST) have limitless potential exploitations. It
all depends on what your requirements are.
Suppose you have N (2) separate fields all of which need to
for serialization is the imagination.
Kenneth
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Rob Scott
Sent: Monday, November 04, 2013 2:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
PLO CSDST and CSTST
Thanks Kenneth. Excellent example. I didn't consider that the load for the
counter must be first to cause the serialization.
Jon Perryman.
From: Kenneth Wilkerson redb...@austin.rr.com
I have used PLO almost exclusively for serialization in multi-address
Thanks Binyamin. Also a great example but it brings me to another question.
What is the advantage of using PLO compare and fetch? Is it just saving CPU
time in the case where the counter has changed? Is there another advantage that
I'm not thinking about?
Jon Perryman.
Of Binyamin Dissen
Sent: Monday, November 04, 2013 11:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
My understanding is with multi-threading it is possible that the updates to
the fields may be out of order and thus it is possible to fetch the updated
counter
percent). But only testing can reveal that.
:
:-Original Message-
:From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:Behalf Of Binyamin Dissen
:Sent: Monday, November 04, 2013 11:15 AM
:To: IBM-MAIN@LISTSERV.UA.EDU
:Subject: Re: Serialization without Enque
:
:My
in SA22-7832-09, 7-281 in
SA22-7832-08
Kenneth
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Binyamin Dissen
Sent: Monday, November 04, 2013 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
That won't help
: Serialization without Enque
:
:My understanding is with multi-threading it is possible that the updates to
:the fields may be out of order and thus it is possible to fetch the updated
:counter with the unupdated value1. PLO serializes it.
:
:On Mon, 4 Nov 2013 07:46:51 -0800 Jon Perryman jperr...@pacbell.net
Subject: Re: Serialization without Enque
Thanks for pointing out that it's required to do the PLO COMPARE against the
counter and FETCH of the value otherwise there is no guarantee that value1
is consistent with the counter.
I'm also hearing you say that programs that reference more than a single
@LISTSERV.UA.EDU
Sent: Monday, November 4, 2013 1:06 PM
Subject: Re: Serialization without Enque
This is not correct. The choice to PLO compare and load is not required
since the count is always guaranteed to be swapped after the stores (my last
email). I only use PLO Compare and load for complex chain
Of Jon Perryman
Sent: Monday, November 04, 2013 3:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
As you say, PLO only locks CPU's using the same PLO lock word. For other
CPU's not using the lockword, it is consider multiple unique instructions.
So in the case of the 64 bit
I sure missed that one with the locks.
PLO CDS does exactly what is wanted. It does 2 CS's within the locked
instruction.
PLO CSDST on the other hand only does a single CS followed by 2 ST's. Since 3
separate load instructions (not under PLO control) are required when not in
contiguous
As a last resort, a GRS latch could be used.
Jon Perryman.
From: Tony Harminc t...@harminc.net
On 1 November 2013 16:22, Donald Likens dlik...@infosecinc.com wrote:
I have a situation where I need to serialize processing and cannot use CDS
because the
Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jon Perryman
Sent: 02 November 2013 19:30
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
As a last resort, a GRS latch could be used.
Jon Perryman
4:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Serialization without Enque
My code must be able to run in SRB mode and with locks held. I have a situation
where I need to serialize processing and cannot use CDS because the two
addresses being updated cannot be next to each other (because I use
PLO with the CSDST function (compare swap and double store)
Sent from my iPhone
On 1 Nov 2013, at 20:22, Donald Likens dlik...@infosecinc.com wrote:
My code must be able to run in SRB mode and with locks held. I have a
situation where I need to serialize processing and cannot use CDS
On 1 November 2013 16:22, Donald Likens dlik...@infosecinc.com wrote:
I have a situation where I need to serialize processing and cannot use CDS
because the two addresses being updated cannot
be next to each other (because I use CDS with these two addresses with other
addresses).
CDSG,
96 matches
Mail list logo
