HELIUM is the thread scheduler and memory manager; the core mediator of access to the fundamental shared resources of processor time and memory space. It will use the processor state control and signal handling interfaces in HYDROGEN to schedule threads.

ARGON has a somewhat different execution model to UNIX. Under UNIX, or indeed anything even vaguely like POSIX, you tend to have long-lived processes which spend much of their time blocked waiting for user input or incoming network requests. All consuming memory.

When the machine starts up, it must start all these processes going and set up their internal state; and when it wants to shut down, it has to ask them to go away increasingly bossily.

I think this is inefficient and unnecessary.

An ARGON node will not tend to have long-running user threads sitting around. Indeed, the design tries to keep blocked threads at a minimum, since they have state encapsulated in them that would be hard to recreate if the node crashed.

On my blog, I have documented an approach to CPU scheduling designed for ARGON.

As mentioned in that document, there are a few places threads may "come from"; real time applications may be assigned to a node by an administrator (stored within the node entity), at which point the scheduler may be asked to regularly invoke some real time event handlers, and the real time application may be bound to hardware interrupt sources to handle them.

Also, requests come in over the network from MERCURY and WOLFRAM. MERCURY request handlers get a scheduling priority based upon an administrator-defined table of clients stored in the cluster entity, while WOLFRAM request handlers inherit the scheduling settings of the calling thread.

Finally, idle tasks may be configured cluster-wide or for individual nodes, to try to find uses for spare CPU power. These are the closest to POSIX style daemon processes; they have to respond to shutdown orders when the node is being closed down. However, due to persistent state in ARGON being managed by transactions, it's no great deal to just zap an idle task; it will lose the work it had done since it last comitted, but it should be designed to commit at good moments.

The CPU scheduling priorities can also be used to schedule access to disk bandwidth (to make higher-priority commits more rapid) and WOLFRAM network bandwidth - bandwidth reservation conflicts may be handled by allowing higher priority tasks to cancel existing lower-priority task's reservations, and the scheduling priority may be used by WOLFRAM to calculate the IRIDIUM delivery priorities.

Real Time

I hope to imbue ARGON with good real-time programming facilities in the longer run. To begin with, it will be possible to implement the soft real-time scheduler on any node, in principle, thus allowing it to have real-time tasks configured in its node entity.

Hard real time systems

Hard real time is more challenging. I suspect that only nodes with hard real time hardware (easily-modelled caches, that sort of thing) will be able to provide true hard real time.

However, a soft real time or non real time node can act as an interface between the world of ARGON and a hard real time embedded system programmed in assembly language. It can communicate via a serial link, to provide an entity that allows interaction with the hard real time node.

Memory management

HELIUM also provides basic support for memory management. It does this by actually replacing the heap allocate/deallocate words provided by HYDROGEN with more specialised ones of its own which wrap the original HYDROGEN ones, while enforcing quotas. A memory pool may have an infinite quota, or a finite one. Memory allocated in a pool consumes that pool's quota as well as that of the pool's parents, and allocation will be denied if any quota would be exceeded. When a pool is created it gets the same quota as its parent by default, but may be given any quota less than that instead; but the quota may not be changed after creation. As well as that hard limit, a pool may have a soft limited assigned to it (or reassigned at any point); attempting to allocate beyond a pool's soft limit returns an error code and the handle of the pool that hit its limit (which may be a parent pool), which the application can then use as a hint to run a garbage collection within the affected pool, then revise the soft limit and try again.