Experimental Physics and
Industrial Control System

[email protected] (Tim Mooney) · Fri, 15 Jul 94 12:17:46 CDT

Winans writes:
>
> Kraimer writes:
>
> >The fix is to ha ve the callback routine (after locking) check to see
> >if the record is active. If it is it just reschedules itself again. It
> >does this until it finds the record not active and then sets the value
> >to 0 and calls dbProcess. 
> 
> *I* would say that the /fix/ would be to treat async and sync record
> processing the SAME WAY... leave the record locked and inaccessable
> from start to finish.  The fix you sugest is only a patch for *this*
> single problem that async processing presents.
> 
> The async device support that I have written and have seen written don't
> check the record values again during an async completion phase. 
> Therefore if someone sneaks a value into the record during the PACT=1
> idle time... it will go unnoticed... which is exactly what is causing
> the problem your problem as well.
> 
> I would prefer that the solution to the momentary binary output problem
> also be applicable to the general integrity problem observed in ALL
> fields of a record when it is processed asynchronously.
> 
> 
> The ability for a put (or a get) to operate on a PACT=1 record has
> been a disaster waiting to happen since day 1.  I have no design ideas
> on an overall solution at this time.  Only a desire to see this
> annoyance go away.
> 
> If anyone has any ideas about this, I would like to hear them.  I am
> sure that everyone would go along with a grand repair to this if we
> only had a _reasonable_ idea on how to do it.

The general problem is that we have nominally two types of records
(sync and async) but three types of needs (sync, async_locked, and
async_unlocked).  If you want the *retriggerable* one shot Marty has
inadvertently described, you should implement it as async_unlocked and
stop pretending it's async_locked with a known loophole and a
corresponding bug.  If you want a nonretriggerable one shot, you should
be able to use async_locked and *know* that nobody's going to screw
around with your process() routine, your .VAL field, or your special()
routine while you're not looking.

The steppermotor, motor, and MCA records are other examples of needs
for this distinction.  Currently, an app developer with this need has
no choice but break the rules, and expect to get whipped around if they
change.

Let's legalize async_unlocked with a *standard* mechanism similar in
function to PACT indicating that interruptable work is in progress, and
deny access to async_locked records while PACT=1.  While we're at it,
we might look critically at what's currently allowed while DISV=DISA.

Tim Mooney

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System