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
<2008>
2009
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
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|