My advice: Do Not Spin. If your implementation of a "lock" is to loop until it is available, you are pretty much doomed to failure in some edge cases over which you likely have no control.
You can spin for a while, but then really need to "wait" (or pause) until "posted" (or released) when the resource becomes available.. Note that this is not the same as a CS loop which loops until successful but only re-does things if something has changed. If you can do things with transactional execution, that can be great (especially constrained transactions which require no fallback path). And as of z/OS 2.4 you can rely on that functionality being available, regardless of whether your z/OS is running under zVM or not. The operating system's spin locks are done by spinning while disabled for external and I/O interrupts (well not exactly, because they open "windows" to allow certain external interrupts, such as those from SIGP's, in -- this important for the well-being of the system). And for things like "enabled resources" (ENQ, LOCAL lock), the system may attempt to manage the work unit priorities to give the "holder" some extra CPU time. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
