Re: EQP

[Jason Cozens]

Hi Neal,

I haven't ignored your last post, I've been putting some time into
some research and reading around. I'm in the process of composing a
reply.

>> I see multiprogramming as bad as any real sense of
>> time is lost and all the problems of locking and synchronization arise.
> 
> How do you deal with the following scenario:
> 
> Consider a file server: it must handle multiple simultaneous
> requests; it has shared meta-data needs to be updated; and, that data
> may need to be paged in.
> 

I think I overstated the point about multiprogramming, locking and
synchronization. The difference that I'm trying to achieve is that the
eager queue is implemented in hardware by finite state machines called
QCells. These are fairly simple and run independently of their clients
(processors in this case).

When a processor has been scheduled it would run independently of the
EQP scheduling, so in a naive way each processor would run a single
process with no time-slicing. Once a processor is working it would not
be interrupted by the scheduler, this was the reason for assuming
there was a large number of processors.

Where a new process is created in normal operating systems this would
end up on its own processor. Processors would be returned to the pool
when a process ended.

EQP is just used for managing an EQ data structure and hence an Eager
Queue can be set up. The intention is obviously to use EQP in resource
scheduling.

One of the motivations in the design of what I'm doing was a paragraph
in your paper "A Critique of the GNU Hurd Multi-server Operating
System"

        5.3    Resource Management

        We have noted that although virtualized resources are con-
        venient, they are also often problematic due to inefficient
        resource scheduling and their ineffectiveness when trying
        to realize real-time properties. This former problem is not
        unique to multi-server systems but particularly pressing as
        it appears the techniques used by monolithic kernels to com-
        pensate for lack of local knowledge, namely, introspection of
        high-level functionality to help predict resource usage pat-
        terns, cannot be used by a microkernel where such func-
        tionality is implemented in user-space. We contend that
        an interface is needed to allow unprivileged programs an
        increased ability to influence resource scheduling both re-
        garding distribution and multiplexing.

In this respect the intention is that the information in an eager
queue can be interrogated by the processors (processes) and
processes can affect the state of a system through an eager queue.

There will still be issues such as you mention for example with
file servers etc. Raising these issues is good as I'm having to
start filling in many details I've been sidelining.

I'm not sure of the exact implementation of what I'm doing at
the moment.

I have a very simple working example in Erlang using
UDP multicasts. Erlang can link into c so it would be good
to get some examples linking into the Hurd translators,

As I said above I will be replying to your previous email.
Thanks for all the feedback so far.

Jason.