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: lockset question
From: Till Straumann <[email protected]>
To: EPICS Techtalk <[email protected]>
Date: Wed, 10 Dec 2008 22:39:31 -0800
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  <20082009  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  <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 ·