How is moving 256 bytes relevant to the serialization? If someone doesn't bother to use part of the protocol then the problem is with him, not with the protocol.
http://www.quotationspage.com/quote/26271.html -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Jon <[email protected]> Sent: Friday, August 2, 2019 5:29 PM To: [email protected] Subject: Re: Circular Queue Handling in Assembler >> How is PLO a use case for a multi-tasking circular queue? > Because it can do a pair fo compare and swap operations as an atomic > operation. Does PLO now move 256 bytes? The op needs to update a 4 byte index and 256 byte data area. It's been a very long time since I looked at PLO but I thought it was less than 64 bytes. I could easily be wrong. >> How do you eliminate timing issues, > How do you eliminate timing using a supervisor assist, e.g., ENQ, latches, > locks? >It's up to you to analyze the costs in your environment. The op was worried about CS before or after (timing). Tony's product solved this thru multiple ECB's. Forget about cost and simplify the solution. The element is either on the ready queue, on the free queue or not on any queue (in use by a task). >> deadly embraces > How do you get one in the first place? By making a false assumption. Most notably, someone might not bother to use WAIT, thinking that a spin loop would be quick enough. >> spin lock hangs? > Spin lock starvation I might believe, but no reasonable design will hang. > Also, if you're hitting the service so heavily that spin lock timing is an > issue, you'd better rethink your design. Sorry, I meant spin loop. There are several considerations when implementing a circular queue. It would not take much to overlook something in the design. Jon.
