I'm glad you brought that up because I knew what I have been doing for years was correct but I hadn't taken the time to read the manual on PLO in some time. 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 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 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
