MEM_OS2.ARC

        MEM_OS2.EXE is a more sophisticated version of OS2MEM.EXE, a
program that I wrote earlier last year which displays the results of a
call to the the API function DosMemAvail.  

        This new version is uses the multitasking ability of OS/2 to
bring up a number of threads which execute concurrently and enable the
user to more closely monitor the memory demands of the system.

        The #3 thread repeatedly updates and displays the value 
returned by DosMemAvail, dynamically both as a number and on a bar graph.
The #2 thread displays the time.  The #4 of the concurrent
threads polls the keyboard (in the IO_WAIT mode) to see if the escape key 
is pressed by the user and clears a semiphore if it detects the ESC key.
The main(), #1, function is the thread that handles the signals from these
three other threads; it displays the menu and then sits there blocked
waiting for the semiphore to be cleared by the ESC key thread, and then it 
unblocks, and goes to the DosExitList.  This clears the screen, brings down 
all the threads and exits via DosExit.  Like #1 thread, the #4 monitoring
thread for the keyboard is also blocked almost immediately, awaiting the
ESC key before is contiues.  Thus, almost immediately after the program 
is loaded, threads #1 and #4 are blocked, while threads #2 and #3 run as
IDLETIME treads.  This is how OS/2 works:  blocked threads use no processor
time, but they are ready for action when needed.  Only those threads which
need precessor attention should be running.  It seems like most of the time
is spent in #2, because that thread uses the printf() function, while the
#4 uses the VIO subsystem.

        I set the priority for these threads quite low (they run as
IDLETIME processes,  = -20) although the program is begun normally from the
command line, _not_ as a detached process.  In this way I avoided having
to use pop-ups, as I consider them too abrupt to be asthetically pleasing,
and I decreased the load on the processor from the running threads.  The
program is thus designed to use the processor only while it is idling,
because any other process which needs a slice would inevitably get priority 
over these threads. That's the reason that the time and ram display update
rather slowly, especially as the load on the processer increases. In fact,
monitoring the seconds display is a good way to estimate processer load.

        The program is begun by entering its name on the command line or
selecting it from the Program Selector.  It pulls up the threads, which
continue to run until the user presses ESC. In ver 1.0, as you load additional
programs, you can switch back to MEM_OS2.EXE and see how the memory load
has changed downward; as you terminate programs, you can watch the available
memory increase.  With MEM_OS2.EXE running in the forground, the memory
usage of any background processes or other screen groups is dynamically
displayed.  Or you can run MEM_OS2.EXE in a PM window.

        I recompiled the program as WINDOWCOMPAT when I got IBM's ver 1.1,
and it now runs in a window under the Presentation Manager.  It is not 
truely a PM program, of course, but it runs fine in a window.  I like to 
downsize it and put it in a corner of the display with just the time and
available ram showing. Its actually pretty useful.  And, it may as well be
a PM program, because it is just a blocked main() getting signals from the
three running threads.

        Although DosMemAvail is described as a snapshot approach, I have
found that the value returned closely tracks the actual memory available
to the system, because the OS/2 MMU apparantly tries to keep rebuilding the
largest memory block available when a program frees up some memory it was
using.

        This program was developed on a no-name AT clone w/3mg Ram, using
MSC 5.1 and IBM OS/2 ver 1.1.

        If you have any questions about any of this, contact me at 
CompuServe 72261,347.

                                
                                Harve Schiffman
                                2-21-1989