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
