Maybe the OP just wants to implement sched_yield() for the Dignus
compiler runtime?
On 2019-10-20 12:46 AM, Charles Mills wrote:
Thanks!
I suppose some encryption algorithm for which there was no hardware assist
available might be a more practical real-world scenario.
An encryption algorithm may still be interrupted by the OS if it's
accessing memory (page faults etc).
The only code I've seen that implements yield are synchronization
routines. Consider a spin-lock which is spinning on a CS instruction.
You need a mechanism to yield to other tasks otherwise
you will just hog the CPU until the time-slice expires. x86 has a pause
instruction which gives the CPU a hint that a spinlock is in progress.
Compilers implement the __mm_pause() intrinsic
function. I'm not sure if zArchitecture has an instruction like pause?
Most spinlock implementations I've seen have a backoff algorithm using
these intrinsics with a counter until eventually taking the slow-path
with a timer. This is explained well by a Google engineer
who is an expert in lock-free data strucutres
http://www.1024cores.net/home/lock-free-algorithms/tricks/spinning.
You can see a real world example of how a spinlock is implemented using
sched_yield() and a backoff algorithm in boost.
https://www.boost.org/doc/libs/1_38_0/boost/detail/spinlock_sync.hpp
https://www.boost.org/doc/libs/1_38_0/boost/detail/yield_k.hpp
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
