Re: Control dispatcher time-slice?
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 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
Re: Control dispatcher time-slice?
On Wed, May 08, 2024 at 12:59:26PM -0400, Tony Harminc wrote: > On Tue, 7 May 2024 at 01:45, Beate Kawelke > 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
Re: Control dispatcher time-slice?
On Tue, 7 May 2024 at 01:45, Beate Kawelke 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. But as you say, without a good understanding of the algorithms it's not much help. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Control dispatcher time-slice?
On Mon, May 06, 2024 at 10:34:03PM -0400, Thomas David Rivers wrote: > We've got a test (with pthread-created TCBs) that we'd like > to really have dispatched with tiny time slices so we can make > sure things are working correctly... > > But - it seems that all of our time slices are "big" > so we don't get the conflicts we'd like to exercise. > > Is there a way to tell the dispatcher to switch more > quickly between TCBs - so we can get more radical > multi-tasking? > > This is on a zPDT system (L01) with only one "physical" > CPU... so we need the dispatcher to perhaps act in > an atypical way for this exercise. Right now, we're > seeing very little multi-tasking between our TCBs. It's not likely that you can *fully* test that. I've seen a case where the task switch had to happen right between two specific instructions to cause a problem. You could see the interrupt in the system trace table right between them in the standalone dump... On the other hand you can beat on it a bit. Since you have only a single processor, any task which waits will cause a task switch. I've never seen IBM pthreads but assuming they're like regular OS tasks (plus some extras?) here are some posiblities: Do the threads use STIMER (or STIMERM)? If not you could add a a STIMER exit routine to each thread which wakes up over and over each time for a random time interval. At each wakeup the exit waits for a random amount of time (to let other tasks run) and then reissues the STIMER specifying itself as the exit again. This would make the run take longer real time but you might not care about that (as long as it wasn't too long). Another possiblity would be to have a single task which issues STATUS STOP to the other tasks, to run some and stop others (watch out for deadlock?) Use CHAP to change the priority so that the monitor task runs higher then the target pthread tasks. None of the above require authorized code. With authorized code other things might be possible... I once used instruction fetch PER to count every instruction executed in several address spaces -- not something easy to do without a "real" single user test system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Control dispatcher time-slice?
IEAOPTxx has a TIMESLICES= parameter, but the default is 1 (the minimum). On Tue, May 7, 2024 at 12:34 PM Thomas David Rivers wrote: > We've got a test (with pthread-created TCBs) that we'd like > to really have dispatched with tiny time slices so we can make > sure things are working correctly... > > But - it seems that all of our time slices are "big" > so we don't get the conflicts we'd like to exercise. > > Is there a way to tell the dispatcher to switch more > quickly between TCBs - so we can get more radical > multi-tasking? > > This is on a zPDT system (L01) with only one "physical" > CPU... so we need the dispatcher to perhaps act in > an atypical way for this exercise. Right now, we're > seeing very little multi-tasking between our TCBs. > > - Thanks - > - Dave R. - > > -- > riv...@dignus.comWork: (919) 676-0847 > Get your mainframe programming tools at http://www.dignus.com > > -- > 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
