Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 06 Feb 2006 17:13:23 -0600

Redman, Russell wrote:

I am still not clear on the logic of the original behaviour. If I want
to read a value from an asynchronous input record, and I do not care
whether it is up-to-date, I can use an NPP INLINK to fetch the current
value. If I specifically ask for a PP INLINK, that surely indicates
that I need a completely up-to-date value and that stale data is
unacceptable.

The slightly strange behaviour probably stems from the addition of
asynchronous processing to record support somewhat later than the design
of the link API. I'm guessing there as I wasn't involved when this was
written and Marty is no longer 2 doors down from my office, but in any
case I don't see an easy solution to achieving the behaviour that we
would all like - it would require major surgery on the database
processing code and all of the existing record types.
Reading a value through a link is an inherently synchronous operation in
the current API - you call dbGetLink() and expect the result to be there
as soon as the call returns. If the link you're reading has its PP flag
set, dbGetLink() calls the record's process routine first and then grabs
the field value after it has returned.
Asynchronous record processing is by definition *not* a synchronous
operation - you call the record's process() routine, and it will return
almost immediately having started the I/O operation going. There is no
indication to the caller that it hasn't finished, although the caller
could find out if it really wanted to by looking at the record's PACT
field. The I/O operation will finish at some point later (we hope!) and
the associated device support will arrange for the record's process()
routine to be called, after which the new engineering value is available
to be read.
Reconciling the synchronous dbGetLink() call API with the asynchronous
record processing behaviour would require that dbGetLink() not return
until after the I/O operation has completed, which ties up the task that
is doing the dbGetLink() operation - it can't return until it knows the
value is available. We don't know how long that will take though, it
may be half an hour for some devices (extreme, but legal). Since it's
obviously not acceptable to suspend any of the existing scan tasks for
that period of time waiting for one device to finish, we have to accept
that the current design doesn't allow us to implement the behaviour we'd
like for PP links to asynchronous records. [Ben, if you think you have
a working solution I'd love to see it.]
We can't change the record support asynchronous behaviour, so the only
answer is to redesign the dbGetLink() API and make it asynchronous.
That means using a new dbGetLinkCallback() call instead of dbGetLink().
It also means that every routine that calls dbGetLink() would have to
split into (at least) two routines, since everything which currently
follows the dbGetLink() would have to be performed in a callback
routine. There are 49 such calls in src/rec, 7 more in src/db, and an
unknown number in record types that are not shipped with base.
In the long term I'm sure we're going to want to resolve this issue, but
I don't think it's particularly high on the priority list and there are
other changes that we need to make to links which should be included in
any change of this magnitude.
Otherwise, why bother asking for PP?

If you don't ask for PP then (assuming the record has SCAN=Passive) it
would never process so the I/O operation would never get performed at all.
- Andrew
--
* * Matt Santos / / For a Brighter America * *

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System