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 address, PLO CSDST, it is considered compare, store value1, store value2, store swap value. Although it's unlikely, it is possible for the LG instruction to occur after store value1 but before store value2. Or are the stores considered a single occurrance instruction to the other CPU's?
Thanks, Jon Peryman. >________________________________ > From: Kenneth Wilkerson <redb...@austin.rr.com> >To: IBM-MAIN@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 manipulations. But >do it if you want. The serialization performed by a PLO forces serialization >on the lock word for all processors. I try to Avoid it for situations where >a re-drive is less costly > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Jon Perryman >Sent: Monday, November 04, 2013 2:42 PM >To: IBM-MAIN@LISTSERV.UA.EDU >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 >word, must use PLO COMPARE and FETCH. In Kenneth's example where he uses PLO >to save 64 bit addresses (which is 2 words), he can't use LG to reference >the 64 bit address otherwise he risks using high and low register values >that do not match. Is that correct? > >Jon Perryman. > > > >>________________________________ >> From: Binyamin Dissen <bdis...@dissensoftware.com> >> >> >>That won't help if you fetch the new count and the old value1. >> >>On Mon, 4 Nov 2013 11:38:38 -0600 Kenneth Wilkerson >><redb...@austin.rr.com> >>wrote: >> >>:>Yes, it is possible that the updates are not performed in any order. >>:>However, it is guaranteed that the updates are only performed if the >>swap :>can be done. Therefore, I use a simple rule. If the number of >>instructions :>needed to compute the new chain pointers are small (as >>is the case in my :>example). I don't incur the overhead of doing the >>extra 2 PLO (Compare and >>:>Load) operations. I simply re-drive the operation as shown in >>Binyamin's :>example. Even with the PLO Compare and Load, there is no >>guarantee the swap :>will succeed. It just lessens the likelihood. So >>the decision point is :>whether the overhead of 2 additional PLO >>instructions is less than the :>overhead of a re-drive. This can only >>be determined with testing. You can :>determine this by using a CS to >>update a counter for every re-drive. You :>already have an operation >>count, so you can then easily determine the :>percentage of re-drives. >>In my experience, even in very active chains, the :>PLO serialization >>process will incur a very small number of re-drives (much :>less than 1 >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 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> >wrote: >>:> >>:>:>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. >>:>:> >>:>:> >>:>:> >>:>:>>________________________________ >>:>:>> From: Binyamin Dissen <bdis...@dissensoftware.com> :>> :>> :>> >>:>>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 >>:>:>> CC>0, go to A >>:>:>> PLO compare-and-fetch value 2 :>:>> CC>0, go to A :>:>> >>calculate new value1 and 2 :>:>> Add one to fetched counter :>:>> >>PLO CSDST fetched-counter new-fetched-counter, new value1, >>:>new-value2 :>> CC>0, go to A :>> :>> :>> :> >>:>:>------------------------------------------------------------------- >>--- :>:>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 >> >> >> > >---------------------------------------------------------------------- >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 > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
