Experimental Physics and
Industrial Control System

[email protected] · Fri, 15 Jul 94 13:46:30 -0500

This is just some extra comments in reply to both John Winans and Tim Mooney.

> 
> 
> 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

1) Caching puts do solve a large part of the problems that previously existed.
   This solves part of the problem of something outside of record processing
   writing values while pact is true. It means that there will be a extra
   process request to take care of any values written to the record between
   asyn start and asyn completion.
2) The momentary binary output was done incorrectly because it wanted the
   equivalent of a caching put. It was not however calling a routine
   that honors caching puts. This it must do something to ensure that its's
   request causes processing. Checking PACT and rescheduling if it is TRUE
   solves the problem.
3) This still does not solve the problem of someone stuffing values into a
   record between asyn start and asyn completion. I agree that this could be a
   problem for some records.
4) There can also be a problem with disabled records.Note that it is possible to
   put a disabled record into alarm while it is disabled. If the severity is
   invalid then at least no client will be mislead about field values.
5) Regarding Tim's idea of asyn_locked we could just deny all put requests
   between the two phases of asyn processing. In some cases this might be
   ok but I can also think of problems. It may be ok for some fields
   to get changed but not others.  

I think that the problem can be stated as follows: 1) For asyn records what do
we do if anyone besides that record's support module attempts
to write into one or more fields of the record between asyn start and asyn
completion? 2) Are gets always meaningfull if values are read between the two
phases?

Please note that NO problem exists for synchronous records that are not
disabled. Record locking causes requests arising from outside the database
to queue. For release 3.11 records are locked for both gets and puts.

Thus the only problems are asynchronous records and disabled records.

Marty Kraimer

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System