Thanks! I suppose some encryption algorithm for which there was no hardware assist available might be a more practical real-world scenario.
> Is there something in the dispatcher that is on a timer that ends up saying > this task has gotten enough CPU and it's time to move to the next TCB? In my way imperfect understanding, yes. I believe there is a hardware feature now wherein MVS can say "give me an interrupt when this CPU has run for nnn CPU microseconds" or something similar. If not, then most operating systems have a concept of the time slice: we will let set a hardware timer for nnn real-time microseconds and when the timer goes off, re-evaluate our scheduling algorithm. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Saturday, October 19, 2019 12:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Best way for a task to give up the CPU and let other tasks run? Great descriptions! I was thinking of the PI calculation myself because that's a case where you're doing real work, but the loop could be coded with no I/O and no SVC calls (which would give up control). Now here's a case I thought about in the past: Assuming I'm running such a PI calculation (non-supervisor, interrupts enabled), what is it that eventually interrupts my running code? Of course there are previous I/O completions from other tasks or CP's, but imagine (maybe on a specialized system?) there's nothing much else going on. Is there something in the dispatcher that is on a timer that ends up saying this task has gotten enough CPU and it's time to move to the next TCB? On 10/19/2019 7:45 AM, Charles Mills wrote: > Others have given you good replies. I've been thinking about your question > and thought I would summarize and re-phrase what has been said. You are not > very specific in what your situation is, so let me offer three possible > problem scenarios, each with its own solution. > > I. "I am doing something that is going to require a whole lot of processing, > like computing pi to a million digits. It occurs to me that I have been > processing for quite some time. I would like to be polite and give others a > chance." > > Solution: Do nothing special. This is the magic of MVS and WLM. Assuming WLM > is set up properly, and you are in an appropriate WLM class, then when their > algorithms decide that someone else deserves to run, they will get to run, > and then after a while you will run again, all seamlessly and transparently, > with no effort on your part. (If that assumption is wrong, then you need to > fix that.) > > II. "My code handles something that happens from time to time, like a > transaction coming in on the wire. There is no work to do at the moment but > there may be shortly." > > Solutions: (a.) Look first at WAIT and POST. WAIT will let your task give up > the CPU until whatever process gives you work indicates that there is > something to do, with POST. > > (b.) If you do not have control of the process that gives you work to do and > so cannot add a POST to it -- perhaps you are monitoring jobs in other > address spaces and watching for something to happen there -- then look at > STIMER WAIT. That will let you give up the CPU for a tenth of a second or > ten seconds or whatever is appropriate. > > (c.) If there is plenty of work to do, but you need some resource that is > currently unavailable -- a file or a common buffer or something like that -- > to be able to do it, then look at ENQ and DEQ. They will let you give up the > CPU until the process that is using the common resource relinquishes it. > > In other words, there is no single magic "umm, I have nothing to do for a > little while; come back to me when I do" service available in MVS without > your specifying a little better what the condition is that will constitute > "something to do." > > III. "Everything you say is well and good, but my code is running in an MVS > exit, or as an SRB, or holds locks, or something like that, which precludes > the use of WAIT and similar services." I think this is not likely your > situation but for completeness I will cover it. > > Solution: yes, take a look at CALLDISP as others have suggested. It's not > the right solution if I. or II. is your situation, but if III. applies, then > yes, this is a possible answer to your question. > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Thomas David Rivers > Sent: Thursday, October 17, 2019 8:54 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Best way for a task to give up the CPU and let other tasks run? > > Does anyone happen to know the best way for a running task > to give up running and let another task run? > > But - this isn't "give up" as in ending the task, just giving up > the CPU to allow another task to run and then returning to this > task. > > Sorta like "I'm done for the moment if something else would like to run". > > - Thanks - > - Dave R. - > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
