🚀 go-pugleaf

Oberon is a single threaded system. To the extent that are multiple tasks
executing within the system, they are each expected to do their work and
return before the next task gets a chance to execute. (This ignores
interrupts, but generally one isn't supposed to run a lot of code at
interrupt time.) Since the system only manages to run multiple tasks by
virtue of each tasking being well behaved, this is known as cooperative
multitasking.

One can also have cooperative multithreaded systems. In these systems,
threads don't have to exit in order to yield time -- i.e., there are
multiple control stacks in existence at one time. Threads do have to
explictily call a yield routine, yielding time either to a specific thread
or to any other thread. Apple's Thread Manager and many multi-tasking
FORTH systems are built on this model. It requires peppering one's code
with calls to Threads.Yield (just to make up a name), but it saves one
from having to write code so that it breaks a computation up into a
sequence of independent task invocations -- e.g., with threads you can
recursively walk a binary tree yielding at every node; without threads you
need to return from your task after every node and save off your location
in the tree in storage associated with your task.

Preemptive multitasking means that threads do not have to explicitly call
a yield routine to give up time. Essentially it means that threads are
both preemptable -- i.e., other threads can gain control -- and preempting
-- i.e., they can get contro -- at any time. Preemptive systems generally
need some form of locking such as semaphores or mutexes to serialize
access to shared data structures. This support needs to be built into the
thread manager since acquiring a semaphore is generally a
multi-instruction process and we wouldn't want to switch threads in the
middle of doing so. In a cooperative system, data structure serialization
can be layered on top of the thread manager.

Preemptive and cooperative threading can be used together. Cooperative
threading, for example, can be built on top of a preemptive thread by
creating a cooperative mutex that each of the cooperative threads needs to
hold to execute. The yield routine then consists of releasing the
cooperative mutex and then reacquiring it.

One could even make preemptive and/or cooperative threads work with the
Oberon single task system. A thread for example could queue itself as a
task to execute the next time the system loop was looking for something to
do. It would run until it yielded the system loop mutex. An oganization
like this would allow the existing Oberon system which doesn't do any data
structure locking to keep functioning more or less as is while allowing
well-behaved preemptive threads to access system data structures. (On the
other hand, there is nothing that would prevent an ill-behaved thread from
accessing the structures directly and bringing the system down.)
Concurrent Oberon did something like this but I don't have the paper handy
so I can't check.

Mark