<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//en">

<!–Converted with LaTeX2HTML 2022 (Released January 1, 2022) –> <HTML lang="en"> <HEAD> <TITLE>Contents of MPTSK: The Task Organization Layer</TITLE>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8"> <META NAME="viewport" CONTENT="width=device-width, initial-scale=1.0"> <META NAME="Generator" CONTENT="LaTeX2HTML v2022">

<LINK REL="STYLESHEET" HREF="MPTSK.css">

<LINK REL="next" HREF="node14_mn.html"> <LINK REL="previous" HREF="node12_mn.html"> <LINK REL="up" HREF="node9_mn.html"> <LINK REL="next" HREF="node14_mn.html"> </HEAD>

<BODY bgcolor="#ffffff" text="#000000" link="#9944EE" vlink="#0000ff" alink="#00ff00">

<H2><A ID="SECTION00044000000000000000"> MPTSK: The Task Organization Layer</A> </H2>

<P> It is nice to be able to switch contexts whenever we choose, but we may desire more. Suppose, for instance, we get to a point in our program where we must wait for, say, keyboard input. Which thread do we switch to? Or suppose we want to send a message to another thread, say, telling the thread it's printout has finished? How do we pass the thread the message? What if the thread is busy?

<P> The MPTSK cluster answers these questions by providing a general-purpose, integrated scheduler and message passing system based on mailboxes (from which the package gets its name). Essentially, MPTSK organizes threads into a powerful (multi)task force!

<P> The MPTSK cluster introduces three new datatypes: tasks (MPTSK), messages (MPMSG), and mailboxes (MPBOX).

<P> Tasks essentially enhanced threads. They are automatically scheduled and need not be explicitly switched between. They can also send and receive messages...

<P> Messages can be any recordtype for maximum flexibility. The structure need only begin with an MPMSG field (for internal message management purposes). Indeed, even tasks and mailboxes are treated as messages...

<P> Mailboxes are the thing which ties tasks and messages together, and makes Mailbox Multitasking work. A hybrid of the queue data structure, a mailbox <EM>either</EM> contains a list of messages <EM> or</EM> a list of tasks (waiting for messages). (See figure)

<P>

<DIV class="CENTER"><A ID="120"></A> <TABLE> <CAPTION class="BOTTOM"><STRONG>Figure:</STRONG> MPTSK: Mailbox ``Message Bank'' Illustration</CAPTION> <TR><TD><IMG STYLE="height: 314.00ex; " SRC="img7.png" ALT="

\begin{figure}\begin{verbatim}Messages Mailbox Tasks
-------- ------...
...a t...
....re (to control multiprocessor access to the mailbox)\end{verbatim}
\end{figure}
"></TD></TR> </TABLE> </DIV>

<P> An apparent disadvantage of Mailbox Multitasking is that it does not come with functions to allow one task to force another to stop or suspend, a feature common in other multitaskers. But this is because Mailbox has been designed to also work in multiprocessor environments, where the scheduler cannot automatically assume the other tasks are suspended while it executes a task. Though I do not have a multiprocessor machine at my disposal, I designed Mailbox to take advantage of multiprocessing environments should they become available, and to better understand issues involved in real concurrent environments.

<P> Actually, Mailbox is easily extended to support sophisticated task control operations due to another feature, its uniformity. Everything, even scheduling, works by sending and receiving messages. More sophisticated operations follow logically and do not need to be tailored. For example, to <B>yield</B> the current task so other tasks can run (useful when polling some condition), the task merely attempts to ``receive'' a processor ``resource'' from its schedule mailbox. It is also possible for a task to specify which tasks (which schedule list) it wants to yield to. Thus, when optimizing performance, a task can implement its own scheduler and ``break'' the strict priority scheduling. Or, for modular programming, a task can duplicate it: a task can multitask itself!

<P> Even the send and receive ``primitives'' are special instances of a general <!– MATH mptsk$\_xfer$() –> <I>mptsk</I><IMG STYLE="height: 133.16ex; vertical-align: 39.11ex; " SRC="img10.png" ALT="$\_xfer$">() function, with flexibility akin to the <!– MATH mpthd$\_switch$() –> <I>mpthd</I><IMG STYLE="height: 25.39ex; vertical-align: 151.40ex; " SRC="img4.png" ALT="$\_switch$">(). Because all task switching and message passing is through a single function interface, any sort of message monitoring, performance monitoring, or task control is possible, simply by patching the desired code into this function. As we will see more of in the next subsection, instead of being big and complicated with every possible feature, Mailbox is simple, so the programmer can quickly tailor her own.

<P> In short, the MPTSK implements prioritized multiprocessor scheduling and simple ``mailbox'' message-passing, based on threads. It introduces the message, task, and mailbox datatypes and a simple set of operations, with which many sophisticated scheduling, communication, and monitoring environments can be easily built.

<P>

<HR>

</BODY> </HTML>