RE: Process Delay

Thanks for the info!

> -------- Original Message --------
> Subject: RE: Process Delay
> From: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
> Date: Mon, January 16, 2006 12:41 pm
> To: RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
> 
> > 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 in 
> hardware, not sure) there's a big loop that loops through all of the 
> active jobs. As each job comes up in the loop, it gives that job a certain 
> amount of time to execute code (a "timeslice") before moving on to the 
> next job.
> 
> Whenever you do a DLYJOB or sleep() or any other function that puts your 
> job into a "wait" state, the system simply doesn't give your program time 
> to execute until a given condition is satisfied.
> 
> If you say "delay for 5 seconds" the system won't give your job CPU time 
> until that 5 seconds is up.
> 
> If you say "delay until 30 seconds is up, or an entry appears on a data 
> queue" then the system checks that data queue for an entry, if there's one 
> there it lets your job continue. If not, it checks to see if the 30 
> seconds have passed.  If neither is true, it runs the next job on the 
> system.
> 
> The same is also true when waiting for data from a terminal.  It suspends 
> your job's execution until there's data (or an error) to be read from the 
> terminal.
> 
> That's why the "loop until %timestamp > target" technique doesn't perform 
> as well.  It doesn't tell the system to resume when a certain condition is 
> true.  Instead, it uses it's whole timeslice checking the current time, 
> then checking it again, then checking it again, etc, until the time is 
> late enough to continue.  Since the program needs to be in memory for this 
> to 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 the 
> system's loop, which means that every other job has to wait for it, it 
> can't just be skipped.  So, while this type of technique would pose no 
> problems if you had a dedicated CPU (such as a PC running MS-DOS) whenever 
> you need to share a CPU or memory or other resources between multiple 
> running processes, the "loop until" technique is a bad idea.
> 
> DLYJOB and sleep() likely call the same underlying MI instruction.  The 
> only difference between then is DLYJOB has a command that has to be 
> parsed, so sleep will be marginally faster (the difference would be almost 
> immeasurable)
> 
> Waiting on a data queue or message queue would be slightly less efficient 
> since 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().  You 
> could use that with a signal handler to have a subprocedure that's run at 
> a given interval. This might be an interesting option if you need to run 
> things on a given interval, such as 2 minutes.
> 
> Using sleep() won't do that.  If you sleep for 120 seconds, then run a 
> porgram, then sleep for 120 seconds, does the program run every 2 minutes? 
> No, because the program takes time to execute.  For example, if the 
> program takes 30 seconds to run, then it's being run every 2:30.  Two 
> minutes for the sleep, and 30 seconds for the program itself to run.
> 
> If you used setitimer() it would actually run every 2 minutes instead of 
> 2:30 because the signal handler gets called every 2 minutes without regard 
> to what it does in between.  (Unless, of course, it's runtime actually 
> exceeds the interval time...  for example, if you called a program that 
> took longer than 2 minutes...)
> 
> Anyway... hope you get the idea.
> -- 
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.