[unios] Re: IPC in the current OO model

[OJ Hickman]

From: OJ Hickman <hickman1@peak.org>

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

> >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 . . . 

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.

A syncronized function might look like:

void function(int param)
{
   syncronize();

   /* Function code */

   clear();   /* Clear the semephore */
}


> >
> >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?

> >> 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].


> >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

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.

_______________________________________________
"Imagination is more important than knowledge."
- Albert Einstein

Omer James Hickman - hickman1@peak.org - ojh@hotmail.com
http://members.tripod.com/~OJ_Hickman - updated 12/28/98

------------------------------------------------------------------------
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