home *** CD-ROM | disk | FTP | other *** search
/ Programmer 7500 / MAX_PROGRAMMERS.iso / INFO / TURBOPAS / CONCUR4.ZIP / CPEXEC.DOC < prev    next >
Encoding:
Text File  |  1988-04-17  |  3.3 KB  |  59 lines
  1.                   CPEXEC - Concurrent Programming Executive
  2.  
  3. In December 1986, Hans Passant released a package called "CONCUR.PAS" which 
  4. allowed concurrent processing in Turbo Pascal 3.0.  This version (1.2) of the 
  5. package provides similar support for Turbo Pascal 4.0.  Until updated 
  6. documentation is provided, that which comes with CONCUR3 will have to suffice 
  7. as the basis for concurrent processing.
  8.  
  9. This version uses Turbo Power's "Turbo Professional 4.0" package.  Minor 
  10. modifications will be required for use with the standard crt unit.
  11.  
  12. There are many improvements that can/should be made to this package to make it 
  13. more useful.  I will be making some myself and hope others will contribute to 
  14. the effort as well.  I welcome comments/updates/suggestions for this package, 
  15. please send them to Sysop, Albuquerque ROS, (505)299-5974, 300/1200/2400-N-8-1 
  16. or to the CompuServe Borland Programming SIG (BOR100).
  17.  
  18. The following lists some of the ideas I've had to make CPEXEC a more general 
  19. purpose concurrent processor:
  20.  
  21. 1. Better documentation.  This file is just the barest of essentials.  I 
  22. wanted to get the package out as quickly as possible and have taken this 
  23. approach to accelerate the process.
  24.  
  25. 2. Better error handling.  As it stands now, CPEXEC has almost no error 
  26. handling and desperately needs it.  For example, a runtime error handler could 
  27. take a look at <CurTask> and either fix the problem or remove the task without 
  28. clobbering the entire system.
  29.  
  30. 3. Better input routine.  I _think_ the screen output routine takes care of 
  31. all the window essentials but the <ReadLn> routine still stops all tasks while 
  32. waiting.  Perhaps a text device driver is the right approach.  Or perhaps 
  33. someone like Turbo Power Software would be kind enough to put the crt global 
  34. variables into a structure (record).  The driver could then use <CurrentTask> 
  35. as a subscript into this structure.  The benefits of doing this are 
  36. tremendous.  As you can see from looking at the ASM code, the program saves 
  37. and restores all the crt globals with each task switch.  By putting these 
  38. variables into a structure, they become effectively "local" to each task.  The 
  39. task switch overhead drops considerably.
  40.  
  41. 4. Better ASM code.  I don't consider myself really fluent with 8086 assembly 
  42. code.  Doubtless some improvements could be made in the task switcher.  For 
  43. example, the <ActiveTask> array could be replaced with a word consisting of 16 
  44. boolean values.  This word would just be shifted along as the code looks for 
  45. the next active task.
  46.  
  47. 5. Better scheduler/dispatcher.  Instead of taking each task as it comes 
  48. along, how about taking each task every one, two, or more times the task 
  49. switcher is activated.  This way, low priority tasks could be installed with a 
  50. value of, say 200.  Every 200 times the task switcher is called, that task 
  51. would get some CPU time.  The rest of the time it would be skipped over so 
  52. other, higher priority, tasks would get the CPU time.
  53.  
  54. 6. Pre-emptive scheduling.  This would provide honest-to-goodness multi-
  55. tasking.  Borland says "...most of the runtime library is reentrant...."  
  56. Until we know exactly which parts are and which parts aren't, reliable pre-
  57. emptive scheduling may be impossible.  DOS' reentrancy problems will also have 
  58. to be considered.
  59.