[Oberon] RE: Input.Time
jmdrake_98 at yahoo.com
Thu Feb 6 18:27:55 CET 2003
--- "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
> 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
> 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(!).
> 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.
John M. Drake
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
More information about the Oberon