The order of stores is unpredictable except that according to the POM, operand 2 (in this case, the count) is always stored last.
" In those cases when a store is performed to the second- operand location and one or more of the fourth-, sixth-, and eighth-operand locations, the store to the second-operand location is always performed last, as observed by other CPUs and by channel programs." Page 7-290 right column top half of page in SA22-7832-09, 7-281 in SA22-7832-08 So it's impossible for the count to be updated before the stores. I've been using and relying on these techniques for years with exhaustive testing under high workloads with re-drive statistics to help me decide the algorithm that I use. It can't hurt to do the PLO Compare and Load. It just adds overhead that is probably more efficiently handled by a re-drive. But it's up to you. I suggest you add redrive counter to your test case and see for yourself. I would be extremely surprised if the re-drive percent were ever higher than a small fraction of 1% no matter how hard you drove the chain. Kenneth -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 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 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
