CPEXEC - Concurrent Programming Executive

In December 1986, Hans Passant released a package called "CONCUR.PAS" which
allowed concurrent processing in Turbo Pascal 3.0. This version (1.2) of the
package provides similar support for Turbo Pascal 4.0. Until updated
documentation is provided, that which comes with CONCUR3 will have to suffice
as the basis for concurrent processing.

This version uses Turbo Power's "Turbo Professional 4.0" package. Minor
modifications will be required for use with the standard crt unit.

There are many improvements that can/should be made to this package to make it
more useful. I will be making some myself and hope others will contribute to
the effort as well. I welcome comments/updates/suggestions for this package,
please send them to Sysop, Albuquerque ROS, (505)299-5974, 300/1200/2400-N-8-1
or to the CompuServe Borland Programming SIG (BOR100).

The following lists some of the ideas I've had to make CPEXEC a more general
purpose concurrent processor:

1. Better documentation. This file is just the barest of essentials. I
wanted to get the package out as quickly as possible and have taken this
approach to accelerate the process.

2. Better error handling. As it stands now, CPEXEC has almost no error
handling and desperately needs it. For example, a runtime error handler could
take a look at and either fix the problem or remove the task without
clobbering the entire system.

3. Better input routine. I _think_ the screen output routine takes care of
all the window essentials but the routine still stops all tasks while
waiting. Perhaps a text device driver is the right approach. Or perhaps
someone like Turbo Power Software would be kind enough to put the crt global
variables into a structure (record). The driver could then use
as a subscript into this structure. The benefits of doing this are
tremendous. As you can see from looking at the ASM code, the program saves
and restores all the crt globals with each task switch. By putting these
variables into a structure, they become effectively "local" to each task. The
task switch overhead drops considerably.

4. Better ASM code. I don't consider myself really fluent with 8086 assembly
code. Doubtless some improvements could be made in the task switcher. For
example, the array could be replaced with a word consisting of 16
boolean values. This word would just be shifted along as the code looks for
the next active task.

5. Better scheduler/dispatcher. Instead of taking each task as it comes
along, how about taking each task every one, two, or more times the task
switcher is activated. This way, low priority tasks could be installed with a
value of, say 200. Every 200 times the task switcher is called, that task
would get some CPU time. The rest of the time it would be skipped over so
other, higher priority, tasks would get the CPU time.

6. Pre-emptive scheduling. This would provide honest-to-goodness multi-
tasking. Borland says "...most of the runtime library is reentrant...."
Until we know exactly which parts are and which parts aren't, reliable pre-
emptive scheduling may be impossible. DOS' reentrancy problems will also have
to be considered.