[unios] Re: IPC in the current OO model

[Anders Petersson]

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


>From: OJ Hickman <hickman1@peak.org>
>> From: Anders Petersson <anders.petersson@mbox320.swipnet.se>
>> >From: OJ Hickman <hickman1@peak.org>

>> >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"?
>
>In my Component System each object has both a MMU protected code segment
>and data segment. Many objects will have very sencitive data structures, 
>[internal states] such as link lists, queeues, etc . . . 

So it's like a shared memory mechanism, then? Yes, in such case they should
block.

>I think that syncronization should be implamented as a kernel function
>that
>blocks the thread untill the semephore is clear then 1) load an
>alternate
>segment regester with the dataseg of the object being entered [this way
>the
>thread has access to both datasegs at once] 2) set the semephore again.

Regardless the implementation, synchronization shouldn't be a kernel
function. We're looking for a micro- or nanokernel design (or even
no-kernel?)... tasks such as synchronization are outside the very minimal
kernel.

>A syncronized function might look like:
>
>void function(int param)
>{
>   syncronize();
>
>   /* Function code */
>
>   clear();   /* Clear the semephore */
>}

This requires voluntarily calling of the semaphore, doesn't it?

>> >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.
>
>Why not have the IPC queue code detect an overflowing buffer and adjust
>the priorities accordingly?

Because that wouldn't always help. If the server is doing hardware I/O, it
isn't helped by higher priority. In addition, adjusting priorities because
of internal problems sounds like asking for trouble.
A better solution would be to increase the buffer size, maybe by using a
free buffer pool. Yes, we might still run out of buffer space, but I don't
think it's possible at all to eliminate such risks. Or does anyone see a
solution?

>> >> 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?
>> >
>
>> 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.
>
>I don't see how a thread can be an object. I see them as 'inhabiting' a
>home
>object and 'visting' far objects. I know, not very abstact or network
>transparent, but maybe fast.
>
>Each thread is physically a CPU state, a sceduler entery, and a stack
>[or set
>of stacks].

Processes as objects is a perfect use of the object system:
The CPU state is data, stored by the process OH (maybe the same thing as
scheduler?). A process uses an executable file to run. Maybe it owns a data
segment, or maybe such things are built-in, in some way. When a process
opens a file, its just a common interobjectual use.
(I'm here using the word 'process' as a thread that doesn't share anything
in "non-objectual" ways - effectively an own process, but which can be run
inside other applications).
My way to do threads was to simply have processes as children of other
objects. However, sometimes you want several threads to do the same thing,
concurrently - multithreading. This I have problems with.

>> >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.
>
>Yes, dividing the object overseer into a heierarcy of suboverseers is
>the next logical step to take. Also simple to implament diferent
>interaction polocies in diferent parts of the system.

This is just the kind of solutions we are looking for. Another example is
stackable CPU scheduling. I can't promise it'll be fast enough thou, even
if I think considerating speed as the judge is, in general, unfortunate.

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