EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

<19941995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index <19941995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Assuring consistent databases....
From: [email protected] (Marty Kraimer)
Date: Mon, 12 Sep 1994 14:21:26 -0600
Nick Rees,

Currently the following is true.

1) What is locked for record processing is a lock set.
2) CA (actually dbPutField) locks before puting and unlocks after.
3) There is no way to ensure that nothing else cause record processing
   between ca puts.


One thing you could do immediately to solve your problem is to let the
related values be sent in an array (the entire array is sent between
lock and unlock). If the put also cause the record to process you have what
you want.

The above probably can not be done with standard record types but you could
easily write a special record type.

Marty Kraimer



> From [email protected] Mon Sep 12 13:33 CDT 1994
> Date: Mon, 12 Sep 94 08:34:54 HST
> From: [email protected] (Nick Rees)
> To: [email protected]
> Subject: Assuring consistent databases....
> Content-Type> : > text> 
> Content-Length: 1506
> 
> Hi,
> 
> How do you insure that if database values are related, they are always
> updated consistently? If I do a number of consecutive channel access
> puts (or gets) - potentially from the network - I want to ensure that
> these operations:
> 
> 1. Don't interrupt processing in a lock set that uses, or changes,
>    these two values.
> 
> 2. Don't get interupted by record processing during the database update.
> 
> I am prepared to guarantee that the CA gets and puts were done
> consecutively, with no ca_pend_io separating them, but I am not sure
> what else is needed.
> 
> I feel that this must be a common problem, but it has bugged me for a
> while, and I haven't got a satisfactory answer yet. (Epics is so
> atomic, and this is a structured data problem.) If there is no
> satisfactory answer, how difficult would it be to provide the feature?
> Without it, I am afraid my servo application will glitch every few
> seconds, which is not a terribly nice feature (it is the classic
> telescope servo - the telescope servo needs UTC, position, velocity
> tuples which are consistent).
> 
> The problem is really the same as the classic `update anomolies' which
> my university days told me were the reason for the `nth normal forms'
> in relational databases. It is also the reason for the existance of the
> mutex semaphore.
> 
> 
> Nick Rees
> 
> Joint Astronomy Centre                    Ph:       +1 (808) 961-3756
> 660 N. Aohoku Place                       Fax:      +1 (808) 961-6516
> Hilo, HI.  96720                          Internet: [email protected]
> 

Navigate by Date:
Prev: EPICS_CMD_PROTO_PORT Marty Kraimer
Next: Xy240 Chris Mayer
Index: <19941995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: EPICS_CMD_PROTO_PORT Marty Kraimer
Next: SVP, subscribtion desire... Vasily Sakharov
Index: <19941995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·