(Now with some actual content.) The standard justification for spin loop is that the area of code in question is executed *very* frequently and is *very* short. In other words, not worth the overhead of an actual WAIT nor the delay in having to get redispatched afterwards. Spin loop is not an ideal strategy but--as long as all goes well--worth the improved performance overall. The biggest problem with spin loop is on a single CP machine when the loop does not terminate properly. If a second CP is available, it can jump in and interrupt the loop. With no second CP in the picture, the loop may go on and on.
That being said, I can't imagine an application program using this mechanism. OTOH, the line between 'problem program' and 'middleware' (akin to OS) can be pretty fuzzy. OP, however, said he wanted to yield CPU to other tasks. Spin loop is designed not to yield to anyone. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Tony Harminc Sent: Monday, October 21, 2019 10:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Best way for a task to give up the CPU and let other tasks run? On Sun, 20 Oct 2019 at 02:32, David Crayford <dcrayf...@gmail.com> wrote: > The only code I've seen that implements yield are synchronization > routines. Consider a spin-lock which is spinning on a CS instruction. Why would any application program on z/OS implement and use a spin lock? Why do the authors of such think they can do a better implementation than the operating system? If you think you need a spin lock on z/OS, you should probably be using transactional execution. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
