OpenTask(i+1, task_findroot, STACKSIZE,
   stacks[i], PREEMPTIVE);

The second parameter to OpenTask is a pointer to a void function which is known as the TaskFunction. A TaskFunction neither accepts nor returns values. Some intertask communications might be simplified if the TaskFunction were allowed to accept a pointer parameter and return a pointer, for example.

The next parameter is the size of the stack which the new task will accept. Determining your stack requirements is important since modules must be compiled with stack checking disabled (/Gs option on MSC).

The next-to-last parameter is a pointer to the actual stack that the newly spawned function will use. If this pointer is null, Conquerrent C will allocate it from the far heap for you. This can be problematic in Large model, as I will comment on later.

The final parameter is the task Attribute which may be either PREEMPTIVE or COOPERATIVE. In preemptive mode, the task will be routinely interrupted by the task switcher. In cooperative mode, the task will retain control until a call to ReleaseTask is made or it terminates. The ability to easily mix preemptable and non-preemptable tasks in the DOS environment is unique to Conquerrent C.

A Conquerrent C application normally prepares several tasks via OpenTask before invoking the preemptive task switcher. Otherwise StartTaskSwitcher, the preemptive task switcher, will find nothing to do and exit. However, once StartTaskSwitcher has been invoked, the active tasks can spawn additional tasks as required. If your entire application operates in a cooperative mode, then you need not invoke StartTaskSwitcher.

To handle preemptive tasks, Conquerrent C switches tasks each time the user-defined timer service routine (INT 1Ch) is invoked. This interrupt is signalled from the system-timer service routine (INT 08h). The system-timer service routine is triggered by a countdown timer in the Intel 8254 Timer chip. The 8254 signals the IRQ0 line in the Intel 8259 interrupt controller. The interrupt rate can be computed by dividing the 8254 clock input frequency (1.19 Mhz) by the pre-programmed timer divisor:

Conquerrent C multitasking could be improved through the use of task priorities. All preemptive tasks running under Conquerrent C are considered equals — each task gets one time-slice each time it gets its turn. If Conquerrent C allowed each task to have a user-defined time-slice, then the developer could establish priorities among tasks. A prioritized system (e.g. DESQview) allows distinctions between "foreground" and "background" tasks.

First, tasks can be terminated explicitly by CloseTask. Althernately, the entire set of tasks can be aborted by CloseAllTasks. A task which closes itself returns immediately. After all tasks have been closed, the task switcher exits and control returns immediately to point the main program where multitasking first began.

The SuspendTask and ResumeTask functions can be used to temporarily put a task to sleep. Although a task may suspend itself, it must then rely on another task to wake it up. If every currently spawned task becomes suspended, the task switcher exits as if CloseAllTasks had been invoked. Conquerrent C does not provide the ability to suspend a task for a specific time period. This would be useful for a task that you wanted to perform every five minutes, for example.

The CurrentTask, AvailTask, IsTaskOpen, and IsTaskActive functions all report on the current state of a task. CurrentTask tells a task what its own TaskID is. AvailTask returns the lowest TaskID which is eligible for an OpenTask. IsTaskOpen tells whether a thread with the specified TaskID has been opened. IsTaskActive is similar but tells whether the thread is suspended or active.

Last, the TaskAttribute function can be used to change the operating mode (preemptive or cooperative) of a task at any time. A task usually only changes its own task attributes and not those of other tasks. I'll provide a detailed description of TaskAttribute later.

Of course, if your application runs purely in cooperative mode, you will not need to use SemProtect on C runtime library functions. This is because the task switcher will not interrupt a running task in cooperative mode.

SemProtect does have one minor limitation. According to the README file on the distribution disk, the original intent was to allow SemProtect to work on both near-call and far-call functions in the same library. This would help facilitate mixed-model programming. The result is that SemProtect can sometimes mistake near-call functions for far-call functions. However, if you use Large model or explicitly declare your user-defined functions as far-call functions, then you should be safe.

In addition to function-level semaphores, Conquerrent C supports traditional low-level semaphores. The GetSemaphore function blocks the calling task until the requested semaphore ID is available. The ReleaseSemaphore function releases a previously held semaphore ID. The documentation does not specify that tasks queued up by GetSemaphore will be unblocked in FIFO order.

Each semaphore requires 120 bytes. Up to 500 semaphores can be defined at once, which would require a total of 120 * 500 = 60,000 bytes of global data. Both SemProtect and the Get/Release functions share the same set of semaphore IDs. This means you must take care not to use any semaphore IDs in Semprotect that you use in GetSemaphore.

The PostTaskMsg function requires three parameters. The first parameter is the TaskID of the message's recipient. The next parameter is a far void pointer to message buffer being sent. The last parameter is the operation code. If the operation code is MSG_NOSYNC, then the task will continue executing after posting the message. If the operation code is MSG_SYNC, then the task will be blocked until the recipient rendezvous with its corresponding PendTaskMsg. There is no timeout option for the MSG_SYNC rendezvous.

The PendTaskMsg call is simpler because the only parameter is the operation code. This implies that tasks can only read from their assigned message queue and nobody else's. If the operation code is MSG_NOSYNC and no message is available, then PendTaskMsg immediately returns a null pointer. If the operation code is MSG_SYNC, the task remains block until it rendezvous with the sender's PostTaskMsg.

Message queues are limited to eight message-buffer pointers. If more than eight messages are pending in a given queue, then subsequent messages to that queue will not be delivered. Removing this arbitrary limitation would make consumer/producer types of tasks, which rely heavily on messaging, easier to implement.

The reference section describes each function including syntax, parameters, return values, and code fragments. Generally, each code fragment describes a nearly complete program. The order in which the reference presents functions is a bit unpredictable. The author's groupings of related functions together makes it more accessible for the first-time reader. However, its more difficult to refer to the functions later since they are not lexically ordered.

Both the tutorial and reference sections are devoid of graphic illustrations. Such illustrations could help diagram such things as task switching, semaphores, and critical sections. The manual could also be improved by adding a formal glossary of parallel programming and multitasking nomenclature. For completeness, the manual should also have an index and a suggested background reading list.

Conquerrent C includes two short applications which visually demonstrate the workings of the multitasking switcher. HEADS is a program which simply starts 16 ASCII heads ("smiley-faces") careening around the screen. Each moving head is spawned as a separate task. The smoothness of the animation demonstrates the efficiency of the task switcher.

SNAKES, the other application, is an arcade-style game in which your character must avoid colliding with randomly moving snakes. Each successive game level adds another snake until 16 snakes are active. Unfortunately, neither application demonstrates semaphores or messages. Additional programs combining multitasking, semaphores, and messages effectively would be very helpful for less experienced developers.

Technical support for Conquerrent C is primarily available via Compuserve e-mail addressed to EASYPLEX id [76216,2376]. Users must mail in their registration cards before they are eligible for technical support. Direct telephone contact is discouraged as evidenced by the complete absence of telephone numbers in the documentation, software, advertisements, and even the phone book.

My development system for this exercise consisted of a 20Mhz 80386 computer with 4MB RAM under MS-DOS 4.01. Applications built with Conquerrent C worked fine in both a DESQview/386 DOS window and a Microsoft Windows 3.0 DOS window. I built the application with Microsoft C 5.1 and LINK v3.65. The target executable was 32K in size when built with Conquerrent C in the Large model. Its predecessor was 24K in size when built with the DESQview API in the same model.

However, I did discover one debugging technique that may be helpful. Since StartTaskSwitcher must wait for all tasks to complete before continuing, I created a "breakout task." The breakout task, started concurrently with the rest, simply waits for a keypress and then shuts down the remaining tasks. If your tasks require keyboard input, then you could set up the breakout task to poll the joystick fire button, mouse button, or other device. Of course, you can still get into trouble if one of your tasks gets stuck while in non-preemptive mode.

void breakout (void) {
   while ( !kbhit() )
     ;
   CloseAllTasks();
   printf("breakout!\n"); }

Volkman, Victor R., "Multitasking with the DESQview API C Library," The C Users Journal, July 1990, Vol. 8, No. 7, pp. 99-109 — This article introduces FINDROOT, a simulation of a parallel-processing program to determine the roots of an equation. The underlying technique is to partition the solution space among CPUs.

In Summary