3.2 Scheduling

Instances of the patterns of these fragments are expected to be executed from BETA co-routines, and such co-routines must tolerate being suspended (de-scheduled) and later re-scheduled as part of the execution of possibly lengthy operations. This means that concurrency control by means of semaphores, monitors, and the like must be established almost as rigourously as had the co-routines been fully concurrent threads of execution.

In return for this increase in complexity, a usually very important reduction in complexity arises from having implicit instead of explicit scheduling. Especially when fitting a new piece into an existing framework it is a great asset to be able to simply spawn the new piece as part of an initalization phase and then have it running along with the rest of the program without changing any of the other parts not directly interacting with this new piece.

In more concrete terms, it works like this: Whenever an operation is about to block, the current component will be suspended. It will be resumed some time later, when the requested IO is available. In the meantime, some other component which has requested IO available or is not waiting for IO will be resumed. In this way the following liveness property of the program is ensured: it will never be the case that a communication operation by blocking delays the continuation of the execution of all of those components which are either (1) not executing a communication operation or (2) executing a communication operation, but has IO of the requested kind available. Of course, any component can still block the whole system by, for example, entering an infinite loop that does nothing.

There are some operations, that may block the entire process for a while. These include gethostbyname, starting a process, and waiting for a process to stop