EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: lockset question
From: Andrew Johnson <[email protected]>
To: [email protected]
Date: Fri, 12 Dec 2008 13:22:29 -0600
On Friday 12 December 2008 05:00:57 Benjamin Franksen wrote:
> PS: Do CA input links behave the same way as 3.13-NPP-NMS input links
> (apart from going through the CA layer)? That is, do they actually dbGet
> the value each time they get processed, or are the target PVs monitored and
> dbGetLink gets the last monitored value?

No, all CA links use monitors, otherwise the dbCaGetLink() would have to 
block.  The CA library doesn't provide a private API for the dbCa link code 
to use, all the local/remote handling happens inside the CA library, so the 
dbCa code has to treat all CA links equally.

I don't see any safe way to get the old behavior without significantly 
breaking backwards compatibility, which we don't want to do.

If we were to try and modify the DB link code to acquire the other record's 
lockset before copying the value from the target field, we'd be in the 
situation where we own one mutex and we're taking another; this is a classic 
setup for deadlock to occur.  Such cases are normally resolved by ensuring 
that the locks are *always* taken in the same order, if necessary by 
releasing one lock, taking the other one and then taking the first again.  We 
could implement that, but our link code now breaks the "no blocking" rule 
since it may have to wait for the other lockset to finish processing, which 
as Till pointed out could take some time.

EPICS locksets allow DB links to work in conjunction with the "no blocking" 
rule; each lockset completely encompasses a complete set of records that need 
to communicate within the context of a single scan task.  As a result of the 
design, all DB link operations are safe and can operate immediately, even on 
an SMP system where multiple processors are running different scan threads 
simultaneously.

The old "NPP NMS input" method of breaking a lockset could be reinstated if we 
could write code for all of our target architectures that would guarantee 
that the act of fetching a field value is going to be atomic (I would be 
willing to relax the rule for string fields since they weren't atomic before 
either).  Unfortunately while fetch is naturally atomic on some targets, and 
I could see how to implement it on a few others, there are a few (especially 
those with software floating-point routines) where I think the only way to do 
that would involve changing the code that writes to the fields as well.  
Since that happens a lot in record and device support code which we can't 
change, I don't think it's possible.

(Sorry, I tried).

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harold Welte

References:
lockset question Till Straumann
Re: lockset question Andrew Johnson
Re: lockset question Benjamin Franksen

Navigate by Date:
Prev: Re: EDM On Focus Related Displays Won't Close John Sinclair
Next: Re: lockset question Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: lockset question Benjamin Franksen
Next: Re: lockset question Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·