[Gbbopen-list] [GBBopen-developer] Handling external events in GBBopen?

[Dan Corkill]

[Since no one else has offered suggestions, I'll chime in.  I'm also CC'ing
this to the broader gbbopen-list, as it involves important general comments
about blackboard applications & GBBopen.]

Christian wrote:
> What is the best way to handle external events in a blackboard application?
> 
> As an example, consider this years ICFPs contest (http://icfpcontest.org/)
> in which the problem was to control a rover with the aid of a stream of
> telemetry and sensor input being delivered over a socket. As new data
> arrives, one would like to integrate this into the information already
> present on the blackboard, possibly triggering new KSs to fire.
> 
> I can think of three basic flavours:
> 
>  1) Use an external process to asynchronously update the blackboard.
> 
>  2) Integrate the reading of the stream and subsequent BB update into the
>     control shell loop.
> 
>  3) Have a designated KS that reads from the stream and update the BB.
> 
> In 1), one obviously need to synchronize somehow to avoid the external
> process changing the blackboard state in the middle of a KSA doing the
> same. 2) looks somewhat attractive but requires changes to a component
> that one perhaps only rarely need to touch? 3) would require some semi-
> careful adjustments of the priority levels to prevent the KS from
> starving the control KSs but I am a bit unsure what would happen if the
> telemetry stream fell silent for an extended period, how would one prevent
> the entire BB application from terminating?

There are a number of strategies that can be used, based on input arrival
frequency and volume and on the way that input data needs to affect
processing.  For infrequent arrival of data, your idea #1 is a good choice.
 Spawn a CL thread (looping process) to read/block on the socket and
whenever input becomes available, signal a user-defined GBBopen event
associated with the new data.  If you are running the Agenda Shell, any KSs
interested in that event will be triggered on the next control-shell cycle.
 Event signaling (and Agenda Shell processing) is thread safe, as is the
creation of new blackboard objects.  If your CL doesn't support
threading/processes, you can use GBBopen's polling function entities (with
careful attention to programming so that the polling functions are invoked
regularly); threading is highly recommended, though.

Problems with this basic approach are that 1) KSs responding to new events
won't be considered until the current control-shell cycle (currently
executing KSA) completes and 2) event objects are created by the Agenda
Shell to hold the event information (on the shell's event buffer), which
becomes expensive at high event volumes.  Other strategies are based on
addressing either (or both) the responsiveness issue or the data-volume
issue.  I'll address these shortly.

Your idea #2 can be implemented easily as a KS, or probably even better as
simply an event function, that is triggered on either
CONTROL-SHELL-CYCLE-EVENT (for processing new data on each cycle) or
QUIESCENCE-EVENT (for processing new data only when all KSAs triggered
previously have completed and the pending-KSA queue is empty).  The socket
can actually be read by this KS/function or, if the socket has to be read
promptly to avoid data loss, a separate thread can read the socket and the
KS/function associated with the control shell is used to process the block
of newly read data for focusing considerations.  This touches on the
important issue of how focusing of problem-solving activities relates to
higher volume input data.  Does every input need to trigger a control
decision (and even KS actions) or are there other activity triggers
(elapsed time, significant events) that cause KSAs to look on the
blackboard for input data that may or may not be needed/used?

Your idea #3 isn't compatible with the one-executing-KSA-at-a-time model of
the Agenda Shell if the stream-reading KSA blocks awaiting new input (or
doesn't complete to allow other KSAs to run).  If the idea is to have a KSA
that reads data, if present, and then always completes immediately (whether
there was any data or not), then you have the KS version of #2 (above).

Being highly responsive to important data read from the socket requires
that this situation be recognized by code associated with reading from the
socket and, if you are running the Agenda Shell, aborting the currently
executing KSA to focus on new highly-rated KSAs associated with the
important input.  An example of how to do this is shown by the
:abort-ks-execution-example module.  Generally it is preferable to abort
(and never restart) an executing KSA rather than try to restart it later
when the context of the blackboard has changed and the decisions that were
made by the KSA up to that point have become outdated.  Advanced forms of
aborting may decide how close the executing KSA is to completion and how
important finishing its activities are versus aborting it.  (A KSA that has
been running for a few seconds and is almost complete may be worth allowing
to finish rather than losing all that work.)

As for having the Agenda Shell terminate when there is nothing to do, the
hibernate-on-quiescence argument to START-CONTROL-SHELL comes in handy.
Setting this to true causes the control shell to sleep until a new event
(or AWAKEN-CONTROL-SHELL) occurs (rather than terminating when the
pending-KSA queue is empty).

Anyway, these are some basic sketches of handling asynchronous (external)
events and input streams in GBBopen applications.  They have been used many
times in full blackboard applications (with KSs and a control shell) as
well as in :gbbopen-core applications that use the blackboard repository
and event machinery (but no control shell).  That architectural choice
depends on whether control decisions of which, when, and on what need to be
made or whether processing can be structured as an always-done response to
events.  I can elaborate further on any of these approaches.

-- Dan






-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.