If this code ever ran on a uniprocessor, it's could bring it to its
knees if the lock field is left locked because cleanup code never ran
after an abend or a random error overlaid the lock field.
Regards, Gary
On 2017-12-19 10:30 AM, Ed Jaffe wrote:
On 12/18/2017 6:02 PM, Tony Harminc wrote:
I wouldn't want to have to argue the case for having an enabled
application program do spin loops. But we don't know the context this
code was found in; maybe it's part of an OS or a standalone program.
In my entire IT career, most of which has been spent developing system
software, I have never once had to resort to a home-grown spin lock.
Long, long ago I authored a FIFO "lock manager" based on the examples
found in the Principals of Operation. It has served us well for
decades. The same logic works whether the pool of locks is local
storage or global storage. As long as both asynchronous units of work
have some way of waiting and being posted (and that might be
SUSPEND/RESUME for preemptible class SRBs), then a spin lock should
*never* be required.
Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone +1.613.523.5500 x216
Email: [email protected]
Visit us online at www.DKL.com
E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
