home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 8 Other / 08-Other.zip / MEM2.ZIP / MEM2.TXT < prev   
Text File  |  1989-03-03  |  4KB  |  75 lines
  1.                               MEM2.ARC
  2.  
  3.         MEM2.EXE is a more sophisticated version of OS2MEM.EXE, a
  4. program that I wrote earlier last year which displays the results of a
  5. call to the the API function DosMemAvail.  
  6.  
  7.         This new version is uses the multitasking ability of OS/2 to
  8. bring up a number of threads which execute concurrently and enable the
  9. user to more closely monitor the memory demands of the system.
  10.  
  11.         The #3 thread repeatedly updates and displays the value 
  12. returned by DosMemAvail, dynamically both as a number and on a bar graph.
  13. The #2 thread displays the time.  The #4 of the concurrent
  14. threads polls the keyboard (in the IO_WAIT mode) to see if the escape key 
  15. is pressed by the user and clears a semiphore if it detects the ESC key.
  16. The main(), #1, function is the thread that handles the signals from these
  17. three other threads; it displays the menu and then sits there blocked
  18. waiting for the semiphore to be cleared by the ESC key thread, and then it 
  19. unblocks, and goes to the DosExitList.  This clears the screen, brings down 
  20. all the threads and exits via DosExit.  Like #1 thread, the #4 monitoring
  21. thread for the keyboard is also blocked almost immediately, awaiting the
  22. ESC key before is contiues.  Thus, almost immediately after the program 
  23. is loaded, threads #1 and #4 are blocked, while threads #2 and #3 run as
  24. IDLETIME treads.  This is how OS/2 works:  blocked threads use no processor
  25. time, but they are ready for action when needed.  Only those threads which
  26. need precessor attention should be running.  It seems like most of the time
  27. is spent in #2, because that thread uses the printf() function, while the
  28. #4 uses the VIO subsystem.
  29.  
  30.         I set the priority for these threads quite low (they run as
  31. IDLETIME processes,  = -20) although the program is begun normally from the
  32. command line, _not_ as a detached process.  In this way I avoided having
  33. to use pop-ups, as I consider them too abrupt to be asthetically pleasing,
  34. and I decreased the load on the processor from the running threads.  The
  35. program is thus designed to use the processor only while it is idling,
  36. because any other process which needs a slice would inevitably get priority 
  37. over these threads. That's the reason that the time and ram display update
  38. rather slowly, especially as the load on the processer increases. In fact,
  39. monitoring the seconds display is a good way to estimate processer load.
  40.  
  41.         The program is begun by entering its name on the command line or
  42. selecting it from the Program Selector.  It pulls up the threads, which
  43. continue to run until the user presses ESC. In ver 1.0, as you load additional
  44. programs, you can switch back to MEM2.EXE and see how the memory load
  45. has changed downward; as you terminate programs, you can watch the available
  46. memory increase.  With MEM2.EXE running in the forground, the memory
  47. usage of any background processes or other screen groups is dynamically
  48. displayed.  Or you can run MEM2.EXE in a PM window.
  49.  
  50.         I recompiled the program as WINDOWCOMPAT when I got IBM's ver 1.1,
  51. and it now runs in a window under the Presentation Manager.  It is not 
  52. truely a PM program, of course, but it runs fine in a window.  I like to 
  53. downsize it and put it in a corner of the display with just the time and
  54. available ram showing. Its actually pretty useful.  And, it may as well be
  55. a PM program, because it is just a blocked main() getting signals from the
  56. three running threads.
  57.  
  58.         Although DosMemAvail is described as a snapshot approach, I have
  59. found that the value returned closely tracks the actual memory available
  60. to the system, because the OS/2 MMU apparantly tries to keep rebuilding the
  61. largest memory block available when a program frees up some memory it was
  62. using.
  63.  
  64.         This program was developed on a no-name AT clone w/3mg Ram, using
  65. MSC 5.1 and IBM OS/2 ver 1.1.
  66.  
  67.         If you have any questions about any of this, contact me at 
  68. CompuServe 72261,347.
  69.  
  70.                                 
  71.                                 Harve Schiffman
  72.                                 2-21-1989
  73.         
  74.  
  75.