On Sat, 2011-04-16 at 19:49 -0700, Edward Jaffe wrote: > On 4/16/2011 6:28 PM, Binyamin Dissen wrote: > > ... the basic advantage of the > > PLO is that it avoids the need for locks with non-contiguous serialized > > areas > > if the retry rate is low. > > Also, unlike CD[S], PLO allows for up to 'n' (model dependent) locked > operations > to be performed simultaneously by different, unrelated units of work running > on > the same machine. > > -- > Edward E Jaffe
Please forgive my ignorance, but I don't know what you mean by "n" locked operations to per performed simultaneously. Do you mean that the other three operations: TS, CS, and CDS cause all other CPs in a CEC to stop processing instructions (at an instruction boundary, I would guess) while they execute on the given CP? If so, then YUCK! For some reason I thought that they simply "locked" access to the storage under consideration and stopped other CPs if they tried to access that particular real storage area, but if the other CPs were doing something in another area of storage, that they continued to do normal processing. Is this "stop other CPs in the CEC" what is meant when the PoPs says: "A serialization function is performed before the operand is fetched and again after the operation is completed." And, having read the book again, I see where PLO is __NOT__ referenced in the section on "interlocked update" and now understand why you can't mix PLO updates with the CS/CDS/others. It even lists some other instruction in that section, which I guess means that they can also be used in a multitasking environment to do shared updates. Interesting. I don't write code like this myself, being only a lowly sysprog with delusions of competency. -- John McKown Maranatha! <><
