Introduction

This document goes under the hood and explains the detailed operations of the kernel scheduler. In practice it is never necessary to consider the kernel. We conceptually think of issuing requests into address spaces - the kernel takes care of hiding the complexity of the implementation.

Process Scheduling

A process on the netkernel is initiated by a transport and consists of a series of requests upon Universal Resource Accessors. The figure below shows a simple process execution cycle.

The sequence of steps for the process shown above is as follows, we will assume the process has never executed before and no pre-cached resources are available.

1. An external request is received or generated by a transport. The request is mapped to an internal request (R1) and issued to the Kernel through the Transport Manager. The internal request R1 is placed on the Process Schedule Table (PST) for scheduling by the Scheduler.
2. At some point, determined by the scheduling algorithm, the Scheduler finds R1 on the PST.
3. The Scheduler asks the Module Manager which accessor (URA) is mapped in this module request context to service the request.
4. The scheduler interogates the cache to see if the result of this request is already available.
5. The Cache asks the Module Manager which of the cachelets is responsible for the requested resource. The Cache locates the correct Cachelet and tries to obtain a cached copy of the resource. The Cache request misses and the miss is indicated to the Scheduler.
6. The scheduler issues a request for the URA to the cache, not shown, misses again and therefore constructs an instance of the URA, (URA:1) and places it into the cache.
7. The Scheduler calls URA:1 with the request. URA:1 processes the request. In this example URA:1 requires an additional resource (R2) in order to complete the request. URA:1 issues a new request to the Scheduler for R2.
8. At some point, determined by the scheduling algorithm, the Scheduler finds R2 on the PST.
9. The Scheduler asks the Module Manager which URA is mapped in this application to service the request R2. The scheduler interrogates the cache to see if the resource R2 is already available.
10. The Cache asks the Module Manager which of the cachelets is responsible for the request R2. The Cache locates the correct Cachelet and tries to obtain a cached copy of R2. The Cache request misses and the miss is indicated to the Scheduler.
11. The scheduler issues a request for the URA to the cache, not shown, misses again and therefore constructs an instance of the URA, (URA:2).
12. The Scheduler calls URA:2 with the request for R2. URA:2 processes the request. In this example URA:2 requires an additional resource (R3) in order to complete the request. URA:2 issues a new request to the Scheduler for R3. The request to Schedule R3 proceeds as for R1 and R2 and is not shown. The scheduler calls URI:3 which provides the requested resource R3 without requiring any other resources.
13. The scheduler returns the resource R3 to URA:2, which in return generates it's resource R2 using R3, the scheduler returns R2 to URA:1 which generates the originally requested resource R1. At each stage the cache is given a chance to store the created resource.
14. Finally the resource R1 is returned to the initiating transport where it is delivered as the response to the external request.

In addition to mapping and scheduling requests to URA's. NetKernel also manages underlying threading and resource locking. It manages exception processing, monitors memory and system resource allocation.

NetKernel executes using an underlying threading model which can be scaled from just a single thread through to as many as make sense for the application - this is typically not more than than double the number of CPU's to prevent excessive synchronization costs. NetKernel will detect deadlock in badly behaved URA's and interrupt the URA and issue an exception resource to the failed resource requestor. NetKernel will create additional threads if the number of blocking synchronous requests exceeds the total thread allocation. In general requests are issued asynchronously requiring a minimal number native threads.

NetKernel provides fail-safe thread synchronization for contended URAs. URA's must explicitly be declared thread-safe for the Scheduler to schedule multiple threads to the same URA.

Scheduler State Machine

Each request that enters the scheduler is processed according to the state diagram shown here.

Each state described in a bit mode detail.

map request

The request is mapped by the ModuleManager to determine which module can process the request. The module then determines which accessor can satisfy the request and the original request is rewritten if necessary through any rewrite rules of modules it has passed through to reach the handling module. If no accessor can be found to service the request we move to state exception. The debugger is checked to see if we should move to begin breakpoint or test cache.

begin breakpoint

If a breakpoint is matched the request remains in this state until released.

test cache

Before proceeding the cache is examined to see if a result to the mapped request is available.

get accessor

In this state we check to see if we can get the required accessor from the cache. If it isn't found it is built using the AccessorFactory and placed in the cache. The request then moves into state request representation.

request representation

If the accessor isn't threadsafe and is currently working on another request we move to state busy accessor. Otherwise we proceed to issue the mapped request to the accessor. The request is then placed back onto the PST pending a result from the accessor.

busy accessor

In this state the request is blocked and placed back onto the PST until it is woken by the accessor becoming available again.

released accessor

When the request wakes after being in state busy accessor it enters this state. It has then acquired the lock token on the accessor and proceeds to issue the mapped request to it. The request is then placed back onto the PST pending a result from the accessor.

pending representation

When the request state is reawakened with a result from the accessor it checks to see if is an exception and moves to state exception. If it contains the aspect specified in the request. If it does it moves directly to return result otherwise it moves to state cast representation.

test fragment

If the representation needs to be fragmented it moves to state fragment repesentation otherwise test aspect.

fragment representation

The ModuleManager searches for an IFragmentor that can fragment the representation returned by the accessor using the fragment identifier attached to the request URI. If no fragmentor is found then the request moves to state exception. Otherwise the representation is fragmented and we move to state test aspect.

test aspect

If the representation doesn't have the required aspect it moves to state transrept repesentation otherwise result ready.

transrept representation

The ModuleManager searches for an ITransreptor that can transrepresent the representation returned by the accessor into a representation with an aspect that satisfies the requestor. If no transreptor is found then the request moves to state exception. Otherwise the representation is transrepresented and we move to state result ready.

result ready

The debugger is checked to see if we should enter state end breakpoint otherwise we proceed to return result.

end breakpoint

If a breakpoint is matched the request remains in this state until released.

return result

In this state the result is given to the cache and then returned to the requestor. We then move to state complete.

exception

The exception state can be entered, as previously described from states request accessor and cast representation. It can however also enter this state from any state if that state encounters an exception. These include exceptions in the cache, exceptions from the transreptor and exceptions from the result-returning callback to the requestor. We issue an exception result back to our requestor and move to state complete.