I have used PLO almost exclusively for serialization in multi-address space, multi-du code for almost 10 years. I use all 6 operations. Since everything I write is 64 bit mode, I generally use the +2 variant (64 bit length) but I like using the +3 variant (128 bit length) for some really cool stuff. As Rob pointed out, " The key to their use is to have a lock word counter that the caller increments and then prepares the new values in other regs.". But I add that the real key is designing the application to use PLO for serialization which is much more than just writing macros to do the guts of the processes (though I almost always use macros).
Consider this example. I have a singly linked chain of 64 bit cell addresses on quad word boundaries. The chain pointers are a quad word at the start of the cell. The first double word is the head of the active chain. The second double word is the head of the free chain. The first quad word of each cell is a double word pointer to the next active entry followed by a double word pointer to the next free entry. The chain has a quad word counter on a quad word boundary. The first double word of the counter is a change count. The second double word is an active element count. The algorithm always adds new cells to the head of the list. I can add a new cell by using a LMG to load the counters, increment each counter by 1, compute the new head, compute the old head's new previous and then use a Compare and swap and double store 128 bit to add the new entry. Since every update increments the first double word counter by 1, the process only completes if no other process updated the counter. If the counter has changed, it needs to re-drive. By adding entries to the head, I can also have code simultaneously searching the chain while entries are added. Of course, if the new head is added before the search starts, it won't be found. But that's no different than using a lock. If the search acquires the lock before the add, it won't be found either. I can even add an element that requires a search for one that has already been added. In this case, I load the counters before the search. I search the chain. If not found, I increment the counter and perform the add. If the add fails, I have to re-drive the search. I can also delete entries from the chain. When I find the entry to be deleted, I save its previous entry. I can adjust the counts, re-compute the chain pointers and do a Compare and Swap and triple store to delete the entry and add it to the fee chain. I can still search the chain but I'll probably need to do a Compare and load to do so. I can avoid the PLO compare and load by not actually deleting the cell but using the low half byte of the active next pointer as a deleted flag. But that has disadvantages as well. This also adds a little more logic to the add, since I now need to add using the free chain if one exits or an add acquiring a new cell. There are a lot of details not given here for brevity. This example also uses an unordered single linked list to simplify the example. But properly designed PLO operations can be performed on ordered doubly linked lists as well. When I read the Principles of Operations on the Z/EC12 transactional execution facility, I think strongly of a PLO on steroids. The point is that PLO can almost be used exclusively for serialization. As far as overhead, I have done a lot of testing and the key is the proper choice of the lock word and the algorithm. In my research, the throughput advantages of PLO far outweigh its overhead. I would love some time with the transactional execution facility. From my reading, it eliminates the need for any serialization other than PLO or transactional execution. Though I understand that IBM has chosen a redrive limit as the determining factor as to whether to fall back to a lock. I believe the only limit to using PLO for serialization is the imagination. Kenneth -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Monday, November 04, 2013 2:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Serialization without Enque PLO CSDST and CSTST are *extremely* useful for queue and linked list manipulation in multi-ASID multi-TCB environments. The key to their use is to have a lock word counter that the caller increments and then prepares the new values in other regs. When it comes time to actually atomically update the lock word, you can redrive the structure manipulation logic if the CC indicates that the lock word value has changed, otherwise the other fields are updated atomically. For actual practical uses, it is well worth putting all this inside some sort of macro or small stub service as you do not want to have to code the guts of it each time. I also think the uptake of PLO would be greater if there were some decent example code in the manuals - for instance a client adding a request to the tail of the queue whilst a server is removing from the head. Rob Scott Rocket Software > On 4 Nov 2013, at 03:58, "Jon Perryman" <jperr...@pacbell.net> wrote: > > I sure missed that one with the locks. > > PLO CDS does exactly what is wanted. It does 2 CS's within the locked instruction. > > PLO CSDST on the other hand only does a single CS followed by 2 ST's. Since 3 separate load instructions (not under PLO control) are required when not in contiguous storage, there is not any method that will guarantee the 3 values are consistent with the others. A counter as suggested by Peter Relson won't help either for this same reason. > > > I can't think of a situation where PLO CSDST is useful. Can anyone describe a situation where it is useful? > > Jon Perryman. > > > >> ________________________________ >> From: Rob Scott <rsc...@rocketsoftware.com> >> >> >> >> I think the OP stated that his code could hold locks - in which case the latch services cannot be used. > > ---------------------------------------------------------------------- > 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
