On 6/6/2016 6:54 AM, Steve Smith wrote:
> I'm wondering what an SRB SUSPEND exit is really good for. The
Services Guide and Reference state that it is required, and that it is
supposed to save the SUSPEND token, and decide whether to allow the
SUSPEND. I can't see why the SRB mainline couldn't do those things
itself, and in fact that's the way I've coded it. So, am I missing
something?
Yes, you are missing something.
First, once you issue the SUSPEND the mainline never gets control back
unless the exit decides to terminate the request or a RESUME is issued
using the token. So the mainline *CAN* *NOT* save the SUSPEND token,
which is generated after the SUSPEND is issued, for use on the RESUME.
Second, a timing window exists between the SUSPEND being issued and the
token for it being created where a RESUME would have been performed but
could not be because the token did not yet exist.
The normal suspend protocol is to-
1) In the exit, fetch the suspend token value and check if it is 0.
2) If the token is 0, use compare-and-swap to change the value from 0 to
the new suspend token and complete the suspend.
3) If the token is non-0 or the swap fails then the suspend is
terminated because the resuming code has already run.
4) Set the suspend token back to 0 to prepare for the next suspend
request (it must be initialized to 0 at the start, as well).
The normal resume protocol is to-
1) Fetch the suspend token and check if it is 0.
2) If the token is 0, compare-and-swap in a different specific value,
such as -1.
3) If the token is non-0 or the swap fails then a RESUME is issued using
the suspend token value.
Greg
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
