[unios] Re: IPC in the current OO model

[Anders Petersson]

From: Anders Petersson <anders.petersson@mbox320.swipnet.se>

>From: OJ Hickman <hickman1@peak.org>
>Anders Petersson wrote:
> 
>> But nevertheless thread jumping is an interesting idea. Or rather - the
>> problem that thread jumping would be an answer to is both interesting and
>> important.
>
>High efficiency interaction needed for maximum graphic and multimedia
>throughput. (Note: I do consider speed _very_ important)
>
>Do you have other problems jumping threads solve?

I didn't think of such specific problems, but the general case of
maintaining prioritation when using system-level services. Jumping threads
would solve that, the threads would have to use their own time quota to
perform services for themselves.

>> What should happen when one object make use of another object? The server
>> should process the call with the CPU priority of the client. This supports
>> the jumping threads idea. But the server might have its own idea of how the
>> requested function should be implemented - maybe a single thread is better
>> suited for the task. And what if the client wish to do a non-blocking call?
>> This would have to be circumvented if jumping threads are used.
>
>Not all methods have to block. But if they change the inturnal state of
>the object they will have to block syncronize.

What do you mean with "internal state"?

>> I think a solution with many threads, of which many are woken up only when
>> calls to them are made, is better. Yep - client/server. The client would
>> give the server some of its priority (or all, if the call is blocking), as
>> a "payment". The server itself does not need to have any priority at all -
>> it can just live on time shares donated by clients. (sounds pretty
>> idealistic, don't you think? :) )
>
>Interesting. But if its going to be buffered non blocking IPC the
>data stream consumer will need to have HIGHER priority then the producer
>or the buffers may over run.

Not necessary. All donated time shares are used for whatever the server
wants, which happens to be to finish the first request in the queue. If the
problem still arises, just give the server some prioritation of its own.

>> Or what if both solutions are useful in combination? Sometimes thread
>> jumping is better, sometimes client/server... Other than that it introduces
>> some kernel complexity, I see no hinder to have both, they are both
>> possible in our current design. What do you think of it?
>
>Yes. Direct interaction has one set of advantages/disadvantages and
>cliant/server IPC has its own advantages and disadvantages.

I have to admit that I have a hard time with processes/threads in the mOS
model, especially threads. I don't know how they are to be represented - if
they even can be objects.

>> >The kernel in such a system would do little more then sceduel threads,
>> >allocate raw hardware and memory and provide a linkage database for
>> >the objects to connect to each other.
>> 
>> Almost correct... thanks to OID servers, the kernel does not need to take
>> care of object connections. A "root server" is still needed, I guess.
>> The memory allocation function would have to be provided by the kernel, but
>> could be further implemented by memory servers. The kernel would only
>> provide some sort of root memory allocation.
>> And threads... it's the same thing with them. The kernel implements a
>> simple root scheduler, on which additional schedulers can be stacked.
>
>What is the overhead of all this server stacking? I assume a simple
>system
>could be implamented on the 'root' kernel servers without extra layers
>on top of them?

I can only refer to the document on stacked CPU schedulers:
http://studwww.rug.ac.be/~pdumon/inherit.pdf

Yes, a simple system could be implemented with just a root scheduler, but I
doubt the security against applications sucking up processing power will be
very good. And I don't think real-time processes could be run either.
But since most OSes today can be seen as using only a root scheduler, it's
possible.

>I see the kernel as an oversight unit tracking the objects and the
>dependencies between them. It would also serve as a database of all
>objects - the ones in memory and avalable to be loaded - that
>loads them on a refrence to an object. Also, dependency tracking 
>can identify unused objects and remove them from memory. IS this
>what the OID servers do?

Exactly. Having all objects in a single database would be very clumsy, if
not impossible (removable media). I hope the new mOS document will make
things clearer.

binEng


------------------------------------------------------------------------
To unsubscribe from this mailing list, or to change your subscription
to digest, go to the ONElist web site, at http://www.onelist.com and
select the User Center link from the menu bar on the left.
------------------------------------------------------------------------
UniOS Group
http://members.xoom.com/unios