RE: Process Delay -- RPG400-L

Anyone know how the different techniques (DLYJOB, data queue wait,
sleep(), etc.) really work? I'm curious as to the efficiency of the
different techniques.


This is somewhat simplified, but:

Somewhere in the guts of the operating system (or maybe this part is inhardware, not sure) there's a big loop that loops through all of theactive jobs. As each job comes up in the loop, it gives that job a certainamount of time to execute code (a "timeslice") before moving on to thenext job.

Whenever you do a DLYJOB or sleep() or any other function that puts yourjob into a "wait" state, the system simply doesn't give your program timeto execute until a given condition is satisfied.

If you say "delay for 5 seconds" the system won't give your job CPU timeuntil that 5 seconds is up.

If you say "delay until 30 seconds is up, or an entry appears on a dataqueue" then the system checks that data queue for an entry, if there's onethere it lets your job continue. If not, it checks to see if the 30seconds have passed. If neither is true, it runs the next job on thesystem.

The same is also true when waiting for data from a terminal. It suspendsyour job's execution until there's data (or an error) to be read from theterminal.

That's why the "loop until %timestamp > target" technique doesn't performas well. It doesn't tell the system to resume when a certain condition istrue. Instead, it uses it's whole timeslice checking the current time,then checking it again, then checking it again, etc, until the time islate enough to continue. Since the program needs to be in memory for thisto happen, this might mean moving data into memory for each timeslice.Since it doesn't stop and wait, it gets CPU time every time through thesystem's loop, which means that every other job has to wait for it, itcan't just be skipped. So, while this type of technique would pose noproblems if you had a dedicated CPU (such as a PC running MS-DOS) wheneveryou need to share a CPU or memory or other resources between multiplerunning processes, the "loop until" technique is a bad idea.

DLYJOB and sleep() likely call the same underlying MI instruction. Theonly difference between then is DLYJOB has a command that has to beparsed, so sleep will be marginally faster (the difference would be almostimmeasurable)

Waiting on a data queue or message queue would be slightly less efficientsince the system has to check the queue as well as the clock each time.But again, I doubt you'd ever notice the difference.

There's one option that I haven't seen discussed... setitimer(). Youcould use that with a signal handler to have a subprocedure that's run ata given interval. This might be an interesting option if you need to runthings on a given interval, such as 2 minutes.

Using sleep() won't do that. If you sleep for 120 seconds, then run aporgram, then sleep for 120 seconds, does the program run every 2 minutes?No, because the program takes time to execute. For example, if theprogram takes 30 seconds to run, then it's being run every 2:30. Twominutes for the sleep, and 30 seconds for the program itself to run.

If you used setitimer() it would actually run every 2 minutes instead of2:30 because the signal handler gets called every 2 minutes without regardto what it does in between. (Unless, of course, it's runtime actuallyexceeds the interval time... for example, if you called a program thattook longer than 2 minutes...)


Anyway... hope you get the idea.