MMCC Mid-Michigan Computer Consultants, Inc. Bay City Michigan, ANSI PL/B Language

CONTENTS

v1.10

Mid-Michigan Computer Consultants, Inc.
509 Center
Bay City, Michigan
Sales (989) 892-9242 Support (989) 686-8860

ANSI Standard PL/B Language
DISCUSSION
CPU TIME and WINDOWS

The following information was the response of Ed Boedeker from Sumbelt Computer Systems in response to a discussion group question regarding CPU usage under Windows.

It seems that someone was noticing that a status monitoring tool under Windows was reporting a very high, perhaps it was 100%, CPU usage under certain types of operations where a PL/B program running in a DOS box was simply waiting for keyboard input.

Topic: 100% CPU Usage (3 of 4), Read 42 times
Conf: PL/B
From: Edward Boedecker
Date: Monday, August 31, 1998 10:12 AM

1. Tasks which are executed under Windows95/98/NT are time sliced which means that when a given task has exhausted its allocated execution time slice then that task is automatically suspended while another task is executed. All of this is controlled by things which we all probably should learn but we don't have enough time. This includes ME! The fact that the CPU usage shows a usage value does not mean that the system is out of a resource. It means that the system is being used.

2. David Gabler is correct in that PLBWIN is event driven which means that when Windows has something for the runtime to do, then an event is queued for the runtime to process. This includes the keyboard keyed actions.

3. The PLB386 runtime being a DOS based executable has to continually loop while executing a DOS API to determine if something has been keyed at the keyboard. This action is then causing the PLB386 runtime to use as much of its allocated execution time slice as it can. Notice, that while PLB386 is looping, it is also trying to determine when and if a timeout *T=nnn operation has expired.

Now, that we know why the PLB386 runtime is looping, I need to tell you that the looping action is an indirect reason for the high CPU percent usage. It turns out that PLB386 is generated to be executed by a DOS Extender named DOS4GW. The PLB386 runtime is actually a Linear Executable (LE) file format that gets executed by the DOS4GW DOS Extender. As the PLB386 runtime is looping to fetch current keyboard keyed actions, the DOS4GW has to page the PLB386 runtime code into memory space to be executed. This is causing the high CPU percent usage to appear.

All of this can be expected in that DOS is a single tasking OS environment and there are certain limitations we must live with. However, I can help this situation for a KEYIN only, where I will consider putting a keyword into the runtime which will execute a different DOS API which will cause the PLB386 runtime to stop looping while waiting for a KEYIN. This will reduce the CPU usage because the PLB386 runtime will be idle while waiting for the OS to fetch a character. This can only apply to a KEYIN without an *T=nnn control.

The last thing to consider here under DOS is that you can change the Windows PROPERTIES for the MSDOS command.com shell such that any program executing in that shell would be automatically suspended when that Window becomes inactive or is placed into the background. The PLB386 runtime continues to try to fetch keyed characters even while in the background because it does not know that it is being executed under Windows. This would cause the PLB386 runtime or any other task running in the MSDOS shell to be suspended thus creating more idle time to be used by other active tasks. Note that this may not apply to your application if you are expecting execution to continue even when outside the scope of a KEYIN statement.

4. The PLBCON runtime is somewhere between PLBWIN and PLB386 in its operations. PLBCON is created using the MAKECON utility for those unfamiliar with its usage. PLBCON is a 32 bit application just like PLBWIN except it uses the Windows CONSOLE for all KEYIN and DISPLAY statement operations. PLBCON CANNOT be purely event driven like PLBWIN because the keyboard keyed actions for the CONSOLE are processed differently by Windows. This difference makes it such that PLBCON must also loop, first looking at the Windows queue and second looking for CONSOLE keyboard keyed actions. Therefore, PLBCON cannot be a purely event driven task.

Now what this means is that PLBOCN will have less idle time than PLBWIN and would require more system resource usage. You will also see an increased CPU useage in this case. However, I will consider causing the PLBCON runtime to waste ( go to sleep ) some number of MS which will reduce the CPU usage while in a KEYIN statement.hat PLBCON must also loop, first looking at the Windows queue and second looking for CONS

CONTENTS

v1.10

Send e-mail to MMCC.

Write to MMCC Technical Support at:
MMCC, Inc.
600 W. Midland
Bay City, MI 48708
(989) 686-8860
| Home |
© 1997 MMCC, Inc. All Rights Reserved.
Report problems or suggestions to support@mmcctech.com
Site hosted by Molarnet Technologies

Since 09/14/1998

1.	Tasks which are executed under Windows95/98/NT are time sliced which means that when a given task has exhausted its allocated execution time slice then that task is automatically suspended while another task is executed. All of this is controlled by things which we all probably should learn but we don't have enough time. This includes ME! The fact that the CPU usage shows a usage value does not mean that the system is out of a resource. It means that the system is being used.

2.	David Gabler is correct in that PLBWIN is event driven which means that when Windows has something for the runtime to do, then an event is queued for the runtime to process. This includes the keyboard keyed actions.

3.	The PLB386 runtime being a DOS based executable has to continually loop while executing a DOS API to determine if something has been keyed at the keyboard. This action is then causing the PLB386 runtime to use as much of its allocated execution time slice as it can. Notice, that while PLB386 is looping, it is also trying to determine when and if a timeout T=nnn operation has expired. Now, that we know why the PLB386 runtime is looping, I need to tell you that the looping action is an indirect reason for the high CPU percent usage. It turns out that PLB386 is generated to be executed by a DOS Extender named DOS4GW. The PLB386 runtime is actually a Linear Executable (LE) file format that gets executed by the DOS4GW DOS Extender. As the PLB386 runtime is looping to fetch current keyboard keyed actions, the DOS4GW has to page the PLB386 runtime code into memory space to be executed. This is causing the high CPU percent usage to appear. All of this can be expected in that DOS is a single tasking OS environment and there are certain limitations we must live with. However, I can help this situation for a KEYIN only, where I will consider putting a keyword into the runtime which will execute a different DOS API which will cause the PLB386 runtime to stop looping while waiting for a KEYIN. This will reduce the CPU usage because the PLB386 runtime will be idle while waiting for the OS to fetch a character. This can only apply to a KEYIN without an T=nnn control. The last thing to consider here under DOS is that you can change the Windows PROPERTIES for the MSDOS command.com shell such that any program executing in that shell would be automatically suspended when that Window becomes inactive or is placed into the background. The PLB386 runtime continues to try to fetch keyed characters even while in the background because it does not know that it is being executed under Windows. This would cause the PLB386 runtime or any other task running in the MSDOS shell to be suspended thus creating more idle time to be used by other active tasks. Note that this may not apply to your application if you are expecting execution to continue even when outside the scope of a KEYIN statement.

4.	The PLBCON runtime is somewhere between PLBWIN and PLB386 in its operations. PLBCON is created using the MAKECON utility for those unfamiliar with its usage. PLBCON is a 32 bit application just like PLBWIN except it uses the Windows CONSOLE for all KEYIN and DISPLAY statement operations. PLBCON CANNOT be purely event driven like PLBWIN because the keyboard keyed actions for the CONSOLE are processed differently by Windows. This difference makes it such that PLBCON must also loop, first looking at the Windows queue and second looking for CONSOLE keyboard keyed actions. Therefore, PLBCON cannot be a purely event driven task. Now what this means is that PLBOCN will have less idle time than PLBWIN and would require more system resource usage. You will also see an increased CPU useage in this case. However, I will consider causing the PLBCON runtime to waste ( go to sleep ) some number of MS which will reduce the CPU usage while in a KEYIN statement.hat PLBCON must also loop, first looking at the Windows queue and second looking for CONS