Question

I am working through some of the exercises in The C++ Programming Language by Bjarne Stroustrup. I am confused by problem 11 at the end of Chapter 12:

(*5) Design and implement a library for writing event-driven simulations. Hint: <task.h>. … An object of class task should be able to save its state and to have that state restored so that it can operate as a coroutine. Specific tasks can be defined as objects of classes derived from task. The program to be executed by a task might be defined as a virtual function. … There should be a scheduler implementing a concept of virtual time. … The tasks will need to communicate. Design a class queue for that. …

I am not sure exactly what this is asking for. Is a task a separate thread? (As far as I know it is not possible to create a new thread without system calls, and since this is a book about C++ I do not believe that is the intent.) Without interrupts, how is it possible to start and stop a running function? I assume this would involve busy waiting (which is to say, continually loop and check a condition) although I cannot see how that could be applied to a function that might not terminate for some time (if it contains an infinite loop, for example).

EDIT: Please see my post below with more information.

Answer 1

Hint: <task.h>.

is a reference to an old cooperative multi-tasking library that shipped with early versions of CFront (you can also download at that page).

If you read the paper ‘A Set of C++ Classes for Co-routine Style Programming‘ things will make a lot more sense.

---

Adding a bit:

I’m not an old enough programmer to have used the task library. However, I know that C++ was designed after Stroustrup wrote a simulation in Simula that had many of the same properties as the task library, so I’ve always been curious about it.

If I were to implement the exercise from the book, I would probably do it like this (please note, I haven’t tested this code or even tried to compile it):

class Scheduler {     std::list<*ITask> tasks;   public:     void run()     {         while (1) // or at least until some message is sent to stop running             for (std::list<*ITask>::iterator itor = tasks.begin()                       , std::list<*ITask>::iterator end = tasks.end()                     ; itor != end                     ; ++itor)                 (*itor)->run(); // yes, two dereferences     }      void add_task(ITask* task)     {         tasks.push_back(task);     } };  struct ITask {     virtual ~ITask() { }     virtual void run() = 0; }; 

I know people will disagree with some of my choices. For instance, using a struct for the interface; but structs have the behavior that inheriting from them is public by default (where inheriting from classes is private by default), and I don’t see any value in inheriting privately from an interface, so why not make public inheritance the default?

The idea is that calls to ITask::run() will block the scheduler until the task arrives at a point where it can be interrupted, at which point the task will return from the run method, and wait until the scheduler calls run again to continue. The ‘cooperative’ in ‘cooperative multitasking’ means ‘tasks say when they can be interrupted’ (‘coroutine’ usually means ‘cooperative multitasking’). A simple task may only do one thing in its run() method, a more complex task may implement a state machine, and may use its run() method to figure out what state the object is currently in and make calls to other methods based on that state. The tasks must relinquish control once in a while for this to work, because that is the definition of ‘cooperative multitasking.’ It’s also the reason why all modern operating systems don’t use cooperative multitasking.

This implementation does not (1) follow fair scheduling (maybe keeping a running total of clock ticks spent in in task’s run() method, and skipping tasks that have used too much time relative to the others until the other tasks ‘catch up’), (2) allow for tasks to be removed, or even (3) allow for the scheduler to be stopped.

As for communicating between tasks, you may consider looking at Plan 9’s libtask or Rob Pike’s newsqueak for inspiration (the ‘UNIX implementation of Newsqueak’ download includes a paper, ‘The Implementation of Newsqueak’ that discusses message passing in an interesting virtual machine).

But I believe this is the basic skeleton Stroustrup had in mind.