[Oberon] RE: Input.Time

[John Drake]

--- "Michael A. McGaw" <mamcgaw at ameritech.net> wrote:
> Another use
> for the multitasking (if
> not multiprocessing) is in applications in which a
> given task must be
> preemptable, and yet must preserve its state or
> context.  Here, I am
> thinking of (a kind of) binary tree processing that
> is regularly,
> periodically interrupted (e.g., hard deadlines) so
> that I/O can be performed
> based on the tree processing result at that time,
> and where the state of the
> recursion must be preserved.  This latter example is
> all but impossible to
> implement under NO, as far as I have been able to
> see, but could be easily
> done in BB.

Actually it's not impossible.  I did something 
similair in BlackBox Component Pascal back in 1999.
BBCP uses the same single process multitasking model
as NO.  I was traversing a knowlege tree for an
expert system as opposed to a binary tree, but
since a knowlege tree is just a more complex tree
the same process should work for a binary tree.
Unfortunately I don't have ready access to the
code.  It's on a dead machine and on my CD
backups of that machine (whereever they are)
but as soon as I find it I'll let you know.
Basically I changed what was a recursive process
to an iterative process by modeling it using
a state machine.  While this was a pain at first
the end result was much more efficient code, and
code that I could nicely package into a Windows
DLL (something that I could not do with the initial
recursive version).
 
> I have not studied the internals of BB to know what
> may be possible, but, I
> have considered the following with regard to NO, and
> its GC:
> 
> 1. Remove automatic GC, and instead implement the
> calling of the GC under
> user control.  This must be done with care, as some
> system elements require
> calling GC periodically to function properly.
> 2. Examine the core system for object usage, and
> redesign, where necessary
> and possible, using only statically allocated
> structures.  Without the
> interface handling, the need for dynamic structures
> diminishes, and, in some
> embedded systems, the interface is dispensed with. 
> This approach leaves the
> management of the GC totally at the user's
> descretion.
> 3. Remove GC and use Dispose (!)
> 4. Implement some type of incremental GC, that is
> bounded (e.g.,
> deterministic) in its behavior.
> 
> I have done 1, upon occasion.  4. appears to be the
> most desireable state of
> affairs, from my perspective.
> 
> I would think that 4. would be a very interesting
> project, unfortunately, it
> is beyond my skill (I am trained in aerospace
> engineering, not computer
> science).  An enterprising student may find this
> problem an attractive
> project, however(!).
> 
> Thanks,
> 
> Mike
> 
> Michael McGaw, Ph.D.
> McGaw Technology, Inc.

I've been thinking of a 5th option.  From 
what I've seen of the code BlueBottle has 
a priority based locking mechnism.  The lock
AosLocks.AosHeap hasthe highest priority.  
A new lock could be added AosLocks.AosHardReal 
that has an even higher priority.  Then they 
could interrupt the GC.  There's only one 
catch, but it's a big one.  Such tasks would 
need to be prohibited from doing anything 
that would affect the heap.  I would imagine
that there is a large class of RT problems
that could be handled this way, but this
would require much programming discipline.
But I agree, implementing an incremental GC
is the best overall solution.

Regards,

John M. Drake

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com