17.2. When the Core Runs

17.2. When the Core Runs
Prev	Chapter 17. Threading Model	Next

As the application runs and uses the object model, the Core is entered to peform various operations. Most of the operations are "immediate" operations which means that they are served immediatelly and other parts of the application (or Core subsystems) can not run in the meantime. However there may be blocking operations that can not be served immediatelly - the Core switches temporarily to an another simulation thread and lets the application or the Core run within the context of the other thread until the request can be completed. The blocking operations are the preemption points. Currently, the only allowed blocking operation is a waiting for a SRPC reply.

When the simulation is running the Core is looping in a system loop (see also Section 16.2, “System Interface”). It does its own work and when it receives a request to upcall the application (for example to deliver an object migration), the application is entered. Until the application returns from the upcall the Core will not run. However the application can issue a blocking operation. The application context will then be frozen and the Core will be reentered. Until the blocking operation finishes the Core is looping in a new instance of the system loop (probably also within a context of an another simulation thread) and serves other requests. The application can be upcalled in the meantime, including the object that waits for the completion of the blocking operation. When the blocking operation completes the application will be resumed from the saved context.

	Note
The Core is always looping within a context of a system loop. If an upcalled client code issues a blocking operation, the new instance of the system loop is spawned, current application context is saved and the Core will be looping in the new loop instance. When the blocking operation finishes, the current loop is terminated and the saved context restored. The context saving and restoring is implemented by switching to a different simulation thread. The old thread is suspended (thus the context saved) and a new thread is let run in the meantime. To restore the saved context a switch to the previously suspended thread occurs. Only one simulation thread runs in a time. When there is no free thread the system loop is simply nested (instead of spawning the loop within a context of a new thread, the loop is reentered within the context of the same thread). However the nesting allows to resume saved contexts in LIFO order only (the contexts are saved on the program stack, "older" contexts can not be resumed until "newer" blocking operations complete).

Note

The Core is always looping within a context of a system loop. If an upcalled client code issues a blocking operation, the new instance of the system loop is spawned, current application context is saved and the Core will be looping in the new loop instance. When the blocking operation finishes, the current loop is terminated and the saved context restored.

The context saving and restoring is implemented by switching to a different simulation thread. The old thread is suspended (thus the context saved) and a new thread is let run in the meantime. To restore the saved context a switch to the previously suspended thread occurs. Only one simulation thread runs in a time. When there is no free thread the system loop is simply nested (instead of spawning the loop within a context of a new thread, the loop is reentered within the context of the same thread). However the nesting allows to resume saved contexts in LIFO order only (the contexts are saved on the program stack, "older" contexts can not be resumed until "newer" blocking operations complete).