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 <[email protected]> > > >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 <[email protected]> >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:[email protected]] On >:>Behalf Of Binyamin Dissen >:>Sent: Monday, November 04, 2013 11:15 AM >:>To: [email protected] >:>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 <[email protected]> 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 <[email protected]> :>> :>> :>> :>>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 [email protected] with the message: INFO IBM-MAIN > >-- >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: INFO IBM-MAIN > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
