[Plex86-devel] The plug-in system.......

[Drew Northup]

I was thinking some more about the plug-in system the last couple of days.
I was also thinking about multithreading and IPC.  SYS-V IPC to be
specific.  Since you haven't told me much about what you're thinking--I'll
tell you what I've been thinking about.

1) Multithreading plugin model (not much new..)
2) CPU as a plug-in (discussed earlier)
3) system memory as a plug-in (new, so far as I can tell)
4) each plug-in as a thread or LINUX pthread (not all plug-ins were slated
to be threaded last time I checked....)
5) SYS-V IPC and a message-passing architechture (the message-passing part
is detailed below)
6) separate memory (adjustable size) allocated in the video system to make
future moves toward VESA VBE compliance easier (new, so far as I can tell)
7) internal garbage collection in the message cue (detailed below)

The main thrust of my thinking is this: speeding up the system is
contingent on making the system play nicely in a parallel-processing
manner like a real machine.  I've thought for a good solid two weeks about
this, and i've come to thnk that a message-passing architechture using
SYS-V IPC type communication is the best answer.  This also allows the
monitor-nexus-host communication to be tweaked a little in the process of
implementing the change--which you seem to have shown interest in trying
to pull off.

The IPC shared space would be as follows:
AGESET: an approximate message age initialization counter, used in garbage
collection;
SEM: a simple SYS-V IPC semaphore;
BUFBITMAP: a buffer-space 'bitmap' to show how much message space is free
and where--think filesystem (I'll explain why in a second);
BUFSPACE: the actual buffer space delimited by BUFBITMAP.

A message would be as follows:
V: a validity flag;
AGE: a copy of AGESET at the time that the message was written;
DEST: the destination of the message, the recipient;
SRC: the source of the message, the originator;
MSGBODY: the actual message being passed from one unit to another (length
demarcated in BUFBITMAP).

The elements of BUFBITMAP would be in the form xx where:
00: free;
01: begin message block;
10: end message block;
11: message block body.

Writing a message to the queue would consist of:
1. Check SEM, if false set it and continue; else wait
2. Search BUFBITMAP for a large enough space to place the message to be
posted; if it does not exist, unset SEM and wait
3. write the message to the message block space to be allocated
4. set the allocation bits in BUFBITMAP
5. unset SEM

Reading (and removing) a message from the queue would consist of:
1. Search BUFBITMAP for a begin mark; record
2. Search BUFBITMAP for the matching end mark; record
3. Read the message space for the V flag
4. If the flag is valid then find the DEST and check it for a match to the
current reader's ID; if the ID doesn't match or the flag isn't valid,
re-start the search at the end mark
5. Read in the message
6. unset the V flag--garbage collection will un-allocate the space

Garbage collection works as follows:
1. Search BUFBITMAP for a begin mark; record
2. Check the V flag at the begin mark; record
3. Check the AGE in the message starting at the begin mark; record
4. Check the DEST of the message
5. If the V flag is invalid:
5.1. Set SEM; if it is set, wait
5.2. Un-allocate all space from the current begining to its matching end
mark, and the end mark itself
5.3. Unset SEM
6. If the DEST is invalid:
6.1. Set SEM; if it is set, wait
6.2. Record the SRC of the failed message
6.3. Un-allocate all space from the current begining to its matching end
mark, and the end mark itself
6.4. Unset SEM
6.5. Send the original SRC a message telling it that the original DEST is
invalid
7. If the message block is too old, move the message into a local queue,
and un-allocate its space in the buffer
7.1. Try to get an ACK message from the original desired DEST
7.2. If the ACK fails send the original SRC a failure message that the
DEST has timed out (this could take a couple of passes through the queue
to wait for); if the ACK is returned put the message back on the queue
with a fresh AGE tag

So, I've thought about this a while--What do you think?  Will this code
nicely into the work that you're doing?  How are your experiments going
anyhow?

|^^^ |  | |^^| |^^^  Drew Northup, N1XIM  |^^| |    |^^^ \  / /^^\ /^^~
|__  |  | |  | |    web.syr.edu/~suoc     |__| |    |___  \/  |__| |__
   | |  | |  | |    savannah.nongnu.org/  |    |    |     /\  |  | |  \
___| |__| |__| |___     projects/plex86/  |    |___ |___ /  \ \__/ \__/