Experimental Physics and
| |||||||||||||||
|
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
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
# 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.
| ||||||||||||||
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |