I think the following outlines how this could be achieved just using PLO CSTST.
(o) Have a "lock word" for your ASID-Vector table that is incremented every
time an update is made (does not matter if this values wraps)
AVECHEAD DSECT
AVECHEAD_LOCK DS F
AVECHEAD_AVEC_CPID DS F CPOOL ID for AVEC entries
AVECHEAD_TVEC_CPID DS F CPOOL ID for TVEC entries
AVECHEAD_START DS 0A Start of AVEC slots (each slot
is AVEC address or 0)
(o) "AVEC" describes ASID vector for each entry
AVEC DSECT
....
AVEC_TVEC DS A Top TVEC
(o) "TVEC" describes TCB object
TVEC DSECT
TVEC_PREV DS A
TVEC_NEXT DS A
TVEC_TCB DS A
....
Then for a "TVEC add" function you could do something like :
(1) Load AVECHEAD_LOCK into reg
(2) Copy reg from (1), increment it and store somewhere
(3) Examine AVECHEAD table for existing AVEC for ASID
(4) Build AVEC if required and point a reg at slot (remember if we build new
one)
(5) Build TVEC for new task
(6) Remember existing AVEC_TVEC as OLD.TVEC
(7) Store OLD.TVEC in new TVEC_NEXT
(8) Get address of AVEC_TVEC
(9) PLO CSTST using :
Lockword from (1) and new value in (2)
New Data value 1 is AVEC addr - stored in slot address in (4)
New Data value 2 is TVEC addr - stored at AVEC_TVEC
New Data value 3 is TVEC addr - stored at OLD.TVEC_PREV
(A) If PLO fails, then free TVEC and AVEC (if new) and then go back to (1)
Another alternative is to fully populate your AVECHEAD slots with an AVEC at
server init time
AVEC DSECT
AVEC_LOCK DS F
AVEC_TVEC_HEAD DS A
AVEC_TVEC_TAIL DS A
Then when new tasks are added, you just manage the AVEC queue using PLO. An
ASID being indicated as not being monitored when AVEC_TVEC_HEAD = 0.
Part of me prefers the second method as mutliple AVECs queues can be updated at
the same time and the code is easier - however downside is the increased
storage requirements to fully populate the table at init (and maybe never even
use most of the slots)
Rob Scott
Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: [email protected]
Web: www.rocketsoftware.com
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of
Binyamin Dissen
Sent: 08 March 2010 20:18
To: [email protected]
Subject: Re: Several PLO's versus a SETLOCK
That won't help.
To make it more clear, I have a local ASVT with a slot for each address space.
If a task needs my services I would like to track the address space (in the
ASVT slot) as well as a linked list of the tasks using the service chained off
of the ASCB slot. Additional tasks in this address space may be connecting and
disconnecting.
So if there is already an address space tracking block just chain the TCB block
off of it. If not, allocate one and anchor it. Of course, another task may have
the same idea and there might be two attempts at storing into the slot. Or the
cleanup procedure can detect that all tasks have disconnected and thus there is
no need to retain the address space tracking block.
On Mon, 8 Mar 2010 18:06:38 +0000 Rob Scott <[email protected]> wrote:
:>Binyamin,
:>
:>Why not use the PLO CSTST (compare swap and triple store) ?
:>
:>
:>Rob Scott
:>Developer
:>Rocket Software
:>275 Grove Street * Newton, MA 02466-2272 * USA
:>Tel: +1.617.614.2305
:>Email: [email protected]
:>Web: www.rocketsoftware.com
:>
:>-----Original Message-----
:>From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Binyamin Dissen
:>Sent: 08 March 2010 17:10
:>To: [email protected]
:>Subject: Several PLO's versus a SETLOCK :> :>I need to do a interlocked
update of two disjoint areas. That might include getting storage (if not yet
allocated).
:>
:>The old way would be to setlock, see if the area1 was allocated, if not
allocate and store the anchor1. Then allocate area2 and save its pointer in a
linked list off of area1.
:>
:>The PLO approach is to see if area1 is allocated, and if not allocate both
:>area1 and area2, store area2 in area1 linked list and do a PLO C/S on anchor1.
:>If that fails, do a PLO C/F of the top chain item in area1 store as forward
pointer in area2 next and do a PLO C/D/S with the anchor1 value the same and
setting the forward from area1 to the new area2. If that fails on forward
:>area2 pointer, repeat. If that fails on area1 pointer, repeat top.
:>
:>Obviously the PLO approach is more complicated. But will it save enough
performance on the typical paths so that one can live with the extra cost of
the retries upon failure?
--
Binyamin Dissen <[email protected]> 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
[email protected] with the message: GET IBM-MAIN INFO Search the archives at
http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
