Maybe it's not possible for this situation, but when I would test my own
multi-TCB code, I'd add a temporary STIMER WAIT or similar at a point
where a TCB1 was holding whatever TCB2 was trying to get. That would
force TCB2 to wait or fail or whatever it was supposed to do in such a
case. For all I know those conflicts rarely or maybe even never
happened when running full speed.
On 5/8/2024 4:12 PM, Michael Stein wrote:
On Wed, May 08, 2024 at 12:59:26PM -0400, Tony Harminc wrote:
On Tue, 7 May 2024 at 01:45, Beate Kawelke <beate.kawe...@t-systems.com>
wrote:
You could try to directly change the dispatching priority of a TCB with
CHAP:
https://www.ibm.com/docs/en/zos/2.5.0?topic=hsp-chap-change-dispatching-priority
My understanding is that after changing the dispatching priority for your
task, the dispatcher will get control and (if you downgraded your TCB's
priority) select another task to be run.
Caveat: I don't know enough of the inner workings of z/OS, maybe IBM can
shed some light here...
What about CALLDISP ? As the name suggests, it calls the dispatcher, which
will presumably decide what eligible task should run next. That could well
be the issuer of CALLDISP, but I'd think more likely some other ready TCB
at the same or higher priority.
I'd guess that unless the current task has become non-dispatchable it is
the most likely to be run. I think CALLDISP is usually used by authorized
code which has somehow marked the current task non-dispachable or woken
up some other stream of control of possibly higher priority to give it
a chance to run now.
The idea of using CHAP sounds possible.
The following is all problem program but assumes assumes only one
processor and that the MVS dispatcher usually follows priority order.
I don't know if the existing pthread code issues chap, probably
use of limit priorities can work this if it occurs.
Start with having a "main" task which attaches the starting of the
pthread code at a lower priority such that main is always higher priority.
Then the main task uses chap to alter the relative priorities of it's
subtasks to induce task switches between "high" and "low", both of
which are lower then the priority of the main task.
After the attach the main task loops doing the following:
. check attach completion ECB -> posted then done
. status stop (stop all subtasks)
. scan subtask tree:
. note new or missing tasks
. for each task record
. current instruction counter value
. current priorities
(this catches new tasks or ones which exit,
also catches pthread priority caused changes)
. if one task was set to "hi" priority, issue chap to set it to
"low" priority
. adjust other task priorities as/if needed
. pick a task (random?) and set it to "hi" via chap
. status start
. wait for small or random time
----------------------------------------------------------------------
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
