Re: Record processing: periodic vs. push vs. pull

[Andrew Johnson <anj@aps.anl.gov>]

Hi Jon,

On 2012-12-20 jon@u.washington.edu wrote:
> 1. Periodic
> Pro: i. Record definitions do not depend on control flow, no INP PP or FLNK
>     ii. No control flow subtleties, records always processed on fixed
>         schedule
> Con: i. Processing occurs on fixed schedule, regardless of events or demand
>     ii. Might have to tweak control flow after all, with PHAS
     iii. No obvious connection between the records for processing flow. You
          have to look at several fields to understand what happens, so your
          database is harder for humans to read & follow
      iv. If the ai device support is asynchronous, the CALC can get old data
          from it because there is nothing to make it wait.

Using PHAS at this level is really not a good idea (although there are times 
when you do need it).

> 2. Push
> Pro: i. Processing can be driven by events, when data appears or changes
>         (in input ai, replace SCAN .1 second with I/O Intr or ...)
      ii. Works properly with asynchronous input device support
> Con: i. Input record definitions depend on downstream data processing
>         (must anticipate where data will be consumed to define FLNK)
      ii. Multiple links between records, so if you want to insert a second
          calc you have to change more than one field.
     iii. Can lose data if your output device support is asynchronous and
          slower than the trigger, but probably not a major issue.

> 3. Pull
> Pro: i. Processing can be driven by demand
>         (in output ao, replace SCAN .1 second with input from FLNK or ...)
>     ii. Input record definitions do not depend on downstream processing
     iii. Only one link between records, so more efficient and slightly easier
          to change
> Con: i. Control flow may be difficult to analyze or understand, for example
>         INP PP gets old value instead of waiting for asynchronous
>         completion INP PP flag ignored in CA links (to other IOCs), behaves
>         like NPP
      ii. Very long chains of records need lots of stack space in the thread
          that is executing them.  Usually only a problem with tens or
          hundreds of records though.

> Have I overlooked any important pros or cons?  Is there one
> alternative that is more common, or one that is recommended (or
> discouraged)?

There is a fourth way, using CP or CPP input links to trigger processing 
whenever a new value is available from the previous one.  However this is not 
as efficient since it involves at least one (and maybe 2 or 3) task context 
switch between each record processing.

You can of course mix and match these techniques between different parts of 
your processing chain, so say the CALC might have SCAN set, use Pull to 
trigger the ai and then forward-link to the ao.

HTH,

- Andrew
-- 
Computer science is as much about computers as astronomy is about
telescopes. -- Edsger Dijkstra