Experimental Physics and Industrial Control System
Quoting the AppDevGuide (3.14.8, 3.14.10,
Section 5.4 "Database Locking")
"All records linked via OUTLINKs and FWDLINKs
are placed in the same lock set.
Records linked via INLINKs with PROCESS_PASSIVE
or MAXIMIZE_SEVERITY TRUE are also forced to
be in the same lock set."
I was naively concluding that records linked
via INLINK NPP NMS would _not_ be forced to be
in the same lock set.
However, my database
record (ao, "TST") {
}
record (ai, "TST1") {
field(INP, "TST NPP NMS")
}
and what dblsr has to say:
epics> dblsr("TST1",2)
globalLock 0x8053b50
lockSetModifyLock 0x8053b88
Lock Set 1 2 members epicsMutexId 0x8053c00 Not Locked
TST1
INP INLINK NPP NMS TST
TST
I.e., TST is forced into the same lockset with TST1.
Does anybody know when the implementation deviated from
the documented semantics?
-- Till
PS: This can have a huge impact since locksets can
become a *lot* bigger and the resulting ultra-coarse
locking-granularity can adversely affect the scheduling
of record processing:
Assume you have two high-priority records HI1 and HI2 which
and two low-priority records LO1 and LO2 (in practice: FLNK chains)
which are expensive to process. HI1 schedules processing of LO1 when
done
and so does HI2 with LO2 (e.g., via event scanning, I/O Intr
scanning or scheduling a callback)
The system requires HI1 and HI2 to update quickly with high
priority, LO1 and LO2 should update last.
record ( "HI1" )
field(SCAN, "Event")
field(EVNT, "1")
field(PRIO, "HIGH")
# HI1 posts event 10 from device support
record ( "HI2" )
field(SCAN, "Event")
field(EVNT, "2")
field(PRIO, "HIGH")
# HI2 posts event 20 from device support
# some general info needed by LO1 and LO2
record ( "INFO ")
# expensive, low-priority work consuming
# data from HI1 and INFO
record ( "LO1" )
field(SCAN, "Event")
field(EVNT, "10")
field(PRIO, "LOW")
field(INP1, "HI1 NPP NMS")
field(INP2, "INFO NPP NMS")
# expensive, low-priority work consuming
# data from HI2 and INFO
record ( "LO2" )
field(SCAN, "Event")
field(EVNT, "20")
field(PRIO, "LOW")
field(INP1, "HI2 NPP NMS")
field(INP2, "INFO NPP NMS")
Note: because of the undocumented behavior ALL records will
be in the same lock set.
Now assume that event 1 is posted first, HI1 processes, posts
event 10, LO1 locks (everything since there is only one lock set)
and starts munching. At this point, event 2 is posted (e.g., by
hardware) but HI2 cannot process because it is locked by LO1
processing.
The priority of the cbLow task is probably (if the lockset mutex
has a priority-inheritance attribute) increased to HI
(which could delay other, more important work) for as long as
LO1 holds the lockset.
- Replies:
- Re: lockset question Andrew Johnson
- Navigate by Date:
- Prev:
Re: Support for shell variables in the EPICS build system Andrew Johnson
- Next:
Re: lockset question Andrew Johnson
- 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: Video solutions Mark Rivers
- Next:
Re: lockset question Andrew Johnson
- 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