I meant that compare and swap double was enough to perform the serialization. Triple does not add much. Also, I can theoretically reduce interference by using the address of the ASCB anchor as the lock word.
Using PLO would make the code much more complicated by having to handle multiple failures, such as the anchor changing / being freed and the tcb chain changing. With SETLOCK the code is very simple. On Mon, 8 Mar 2010 23:42:46 +0000 Rob Scott <[email protected]> wrote: :>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
